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

[Neovisual]

I do see some noticeable improvements on some scenes, but the amount of Heap errors im getting its not worth using this.

 

[turtlebackgoofy]

I do see some noticeable improvements on some scenes, but the amount of Heap errors im getting its not worth using this.

you could try previous versions that dont replace the mono runtime.

 

[turtlebackgoofy]

@turtlebackgoofy yo!

I don't know if you're still cooking something on this. But we never know: I isolated a very very weird behavior recently. I'm currently cooking a test var with the situation I have and will create a thread around it to gather some "benchmarks".

I suspect it's related to atom count or simply atoms.

If I do a long story short: I've tested a scene, completely empty, two girls with your CPU patch. Naturalis on both of them and an animation to make things jiggle + 3 lights. I'm averaging at 195fps. If I just add the DreamStreetBedroom, I'm dropping to a 45fps average.

To test my theory, I removed the Bedroom and added ROM enviro of mine which is far more intensive (technically) than that Bedroom. I'm averaging at 165fps with it.

There is something wrong in there, and I don't know why. The only explaination I have is atoms.

So that there is no misunderstanding: this is NOT a report related to your patch. I've tested on my clean VAM used for "QA" prior to pushing each of my releases. I'm averaging at 125/140 instead of 195fps in the empty scene. But the effect is exactly the same.
I'm just reporting this if you potentially were looking for any type of performances issues for your patch.

I created a scene with 2 girls, naturalis, some dance animation, 6 lights, softbody and dreamstreetbedroom and I get around 100 fps. The dreamstreetbedroom has no impact on fps for me.
If you give me a var I can do some profiling, maybe there is some weird interaction that spins the CPU for some reason.

 

[hazmhox]

Sure, I'll do the var file asap : )

 

[gghhoosstt123]

I do see some noticeable improvements on some scenes, but the amount of Heap errors im getting its not worth using this.

patch version 12 works the best for me you should try that one. what are the settings you set in performance config file?

 

[TdotONY]

This patch doesn't give any improvements at all on my system running VAM in VR (which is the only way I use it pretty much). RTX 3080, Ryzen 7800x3D CPU. I copied the settings for the CPU from the overview page as well as the boot.config file settings. I guess since VR is heavier on the GPU than desktop I'm not seeing any change with this CPU patch.

This is running on Win11, Quest Pro through Virtual Desktop with no Oculus or SteamVR software running, using the "VDXR" OpenXR Runtime in the Virtual Desktop Streamer.

 

[mostvanvege]

This patch doesn't give any improvements at all on my system running VAM in VR (which is the only way I use it pretty much). RTX 3080, Ryzen 7800x3D CPU. I copied the settings for the CPU from the overview page as well as the boot.config file settings. I guess since VR is heavier on the GPU than desktop I'm not seeing any change with this CPU patch.

This is running on Win11, Quest Pro through Virtual Desktop with no Oculus or SteamVR software running, using the "VDXR" OpenXR Runtime in the Virtual Desktop Streamer.

View attachment 427540

Of course there isnt, because at this resolution your vga is highly limiting your performance. Try compare 720p desktop mode, you will definitely see what this is about. Or buy a 4080/90..
Your system can only be that fast as your vga or cpu can go, when either hits the limit will prevent go further the other.
Your current pair is cpu heavy, so you could not notice much cpu improvement.

 

[turtlebackgoofy]

This patch doesn't give any improvements at all on my system running VAM in VR (which is the only way I use it pretty much). RTX 3080, Ryzen 7800x3D CPU. I copied the settings for the CPU from the overview page as well as the boot.config file settings. I guess since VR is heavier on the GPU than desktop I'm not seeing any change with this CPU patch.

This is running on Win11, Quest Pro through Virtual Desktop with no Oculus or SteamVR software running, using the "VDXR" OpenXR Runtime in the Virtual Desktop Streamer.

View attachment 427540

Huge improvement in frame times, the worst is 7.93ms avg in baseline3, which translates into 126fps. You have configured something wrong in your oculus drivers which lock the framerate to 45fps. VAM creates atleast 126fps in all your benchmarks, but only 45fps arrive in your headset for some reason, nothing I can do about it.

 

[TdotONY]

Huge improvement in frame times, the worst is 7.93ms avg in baseline3, which translates into 126fps. You have configured something wrong in your oculus drivers which lock the framerate to 45fps. VAM creates atleast 126fps in all your benchmarks, but only 45fps arrive in your headset for some reason, nothing I can do about it.

I'm not using any oculus software on my PC in this example. This is with the Quest Pro connected to my PC through Virtual Desktop, with no Oculus or SteamVR software running at all (custom launch shortcut to launch VAM only with VD), with ASW in Virtual Desktop disabled.

If ASW were running, I would not be seeing FPS numbers like 70 in Baseline 1 or 60'ish in the other ones because it would just cut the FPS to 45 since it's too far away from 90.

I was seeing similar results when running these tests with my Valve Index with SteamVR's Motion Smoothing disabled. No real performance gains.

I see now the Physics Time and Total Time's are improved when running the patch, but I guess since my GPU is the weak link for VR it's not translating to any actual performance improvements.

nvidia 5000 can't come soon enough

 

[turtlebackgoofy]

I'm not using any oculus software on my PC in this example. This is with the Quest Pro connected to my PC through Virtual Desktop, with no Oculus or SteamVR software running at all (custom launch shortcut to launch VAM only with VD), with ASW in Virtual Desktop disabled.

If ASW were running, I would not be seeing FPS numbers like 70 in Baseline 1 or 60'ish in the other ones because it would just cut the FPS to 45 since it's too far away from 90.

I was seeing similar results when running these tests with my Valve Index with SteamVR's Motion Smoothing disabled. No real performance gains.

I see now the Physics Time and Total Time's are improved when running the patch, but I guess since my GPU is the weak link for VR it's not translating to any actual performance improvements.

nvidia 5000 can't come soon enough

I really dont think its the matter of GPU. Baseline1 had a frametime of 3.27ms avg, which means out of 1000ms of a second it took just 3.27ms to finish a full vam frame, corresponding to 305fps. The actual fps in baseline1 however was 70fps, here is a chart:

The benchmark measures the time between when unity starts rendering a frame and the frame beeing ready to be delivered to the display. Something outside of VAM is eating a lot of frametime. With pimax HMD for example if you enable parallel reprojection it puts the finished frame onto a virtual display and renders it with two cameras again, hugely increasing the frametime outside VAM. I suspect your oculusvr or virtualdesktop is doing something similiar.

 

[mostvanvege]

I really dont think its the matter of GPU. Baseline1 had a frametime of 3.27ms avg, which means out of 1000ms of a second it took just 3.27ms to finish a full vam frame, corresponding to 305fps. The actual fps in baseline1 however was 70fps, here is a chart:
View attachment 427858

The benchmark measures the time between when unity starts rendering a frame and the frame beeing ready to be delivered to the display. Something outside of VAM is eating a lot of frametime. With pimax HMD for example if you enable parallel reprojection it puts the finished frame onto a virtual display and renders it with two cameras again, hugely increasing the frametime outside VAM. I suspect your oculusvr or virtualdesktop is doing something similiar.

I might not understand correctly, but as far as I know theese standalone glasses - like quest series - use an encoded livestream from the pc which they decode on the headset. So the calculated fps is what the pc produces for the stream, the actual fps on the headset is after decoding, so it does not really modify the results of the benchmark in vam. So if there is less fps in benchmark then should be, there is most likely set an fps cap somehow on pc. Like with rtss or via gpu driver, but in this case it should work similar in desktop mode too..
So I am still not sure if its not simply vga weakness issue.

Also there is a good tool released some time called presentmon from intel, its like afterburner, but gives you “gpu busy” metrics comparing frametime with gpu rendertime. For a highly gpu bottlenecked case that should be like equal, meaning the cpu has long rendered the next frame for the gpu while that works on a given frame.
Its not a holy grail data, but might help certain situations understand more.

 

[Da_Pig]

The DreamStreetBedroom is a bundled asset in vanilla VAM. You can find it in the "Environments" category when you add an atom : )
It's super old, has probably a stupidly low end geometry (low polycount), textures and materials are barely on par with modern games.

ROM enviro, on the other end is mine. It has a far biggest polycount, dozens of shaders, including custom triplanar shaders, pbr shaders, transparency shaders, custom reflection probes and all that jazz. I'm using the "dynamic version" in that test (so no baking) to be somewhat in the same situation.

The logic would be that ROM would be the one with the bigger overhead. Which is not. And the only difference between the two is that, the bedroom is a "custom meshed atom" (with sub-atoms and everything). And mine is a Custom Unity Asset with simply geometry and graphical assets.

From a pure "asset" perspective (enviro, with models, materials and textures). This makes no sense. The only thing that would trigger that heavy frametime loss, for me, is the fact that the bedroom is a somewhat complex atom.

I'm leaning on that reason because working with VAMStory, i noticed a HUGE difference between a 40 buttons setup made with VAMStoryActions (where the plugin simply instanciate custom UI prefab), and a 40 buttons setup made with 40 different UIButton atoms. It's at a point, where that much button as atoms (UIbutton) can suck out almost 30fps on some PCs when VAMStory has almost no impact with a single atom.

The reason the buttons rob so much fps might be the way they are made - I say might because I have no idea if this is indeed the case, just offering a possibility. Most Unity versions are known to struggle with multiple canvases. If the buttons are made with a separate canvas each, instead of being children of a single world space canvas, that could be the issue. Or very wasteful code in the plugin but I don't think that would be the case.

 

[Gay Sex]

Small question, I have AMD Ryzen 5 5500 so idk options I should use because it's not on the list, and I'm not a nerd enough to know what I'm doing so I don't want to mess around and accidentally mess something up

Note: I've read the instructions and I understand about half the words, I get the gist but give me a simple explination, thanks

 

[Maximum Pleasure]

I'm also confused with how to setup the config file. The main post doesn't really explain properly how to set it up and it's very vague. I have an AMD Ryzen 7 5800X. I found my 2 fastest cores using Ryzen Master, I figured that much out. This is my SkinMeshParDLL.ini file right now, is it correct? Note: I only play in VR mode.

[threads]
computeColliders=8
skinmeshPart=8
applyMorphs=8
skinmeshPartMaxPerChar=8
applyMorphMaxPerChar=8
affinity=1,3,5,7,9,11,13,15
engineAffinity=11,15

[threadsVR]
computeColliders=8
skinmeshPart=8
applyMorphs=8
skinmeshPartMaxPerChar=8
applyMorphMaxPerChar=8
affinity=1,3,5,7,9,11,13,15
engineAffinity=11,15

[profiler]
enabled=0

And here is my boot.config

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

 

[Seraphim]

Just hitting limits i guess

 

[qssrmcnipxfruiutbl]

Just hitting limits i guessView attachment 430977

For sanity checking, same hardware, mild negative curve offset on cpu, fully stock gpu.

I saw ~200% avg fps gains on my 5950x. But the 9800x3d is basically fine out of the box. Still better when patched though.

1080:

4K:

*fixed affinity text to avoid confusion

[threads]
computeColliders=8
skinmeshPart=8
skinmeshPartMaxPerChar=8
applyMorphs=8
applyMorphMaxPerChar=8
#affinity=1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16
affinity=1,3,5,7,9,11,13,15
engineAffinity=1,9

+

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

 

[mostvanvege]

For sanity checking, same hardware, mild negative curve offset on cpu, fully stock gpu.

I saw ~200% avg fps gains on my 5950x. But the 9800x3d is basically fine out of the box. Still better when patched though.

1080:
View attachment 431414
View attachment 431415


4K:
View attachment 431416
View attachment 431417


[threads]
computeColliders=8
skinmeshPart=8
skinmeshPartMaxPerChar=8
applyMorphs=8
applyMorphMaxPerChar=8
#affinity=1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16
affinity=1,3,5,7,9,11,13,15
engineAffinity=1,8

+

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

You sure wanted “engineaffinity=1,8”?!
It would mean the 2nd thread is forced an a HT core..

 

[turtlebackgoofy]

For sanity checking, same hardware, mild negative curve offset on cpu, fully stock gpu.

I saw ~200% avg fps gains on my 5950x. But the 9800x3d is basically fine out of the box. Still better when patched though.

1080:
View attachment 431414
View attachment 431415


4K:
View attachment 431416
View attachment 431417


[threads]
computeColliders=8
skinmeshPart=8
skinmeshPartMaxPerChar=8
applyMorphs=8
applyMorphMaxPerChar=8
#affinity=1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16
affinity=1,3,5,7,9,11,13,15
engineAffinity=1,8

+

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

exactly as predicted, thanks for confirming my predictions of the X3D-Cache

 

[qssrmcnipxfruiutbl]

You sure wanted “engineaffinity=1,8”?!
It would mean the 2nd thread is forced an a HT core..

Wups, that was a typo, should've been 1,9.
Fortunately was only present in my real install, not any of the temp installs that I'd spun up to test with. So no impact. to the screenshots.

It did make me curious though, so I spun up another new install and tested various incorrect affinity choices.
I think I don't have a good hardware config to demonstrate any meaningful differences, as you can see below. Looks like I'm more limited by random background processes causing run-to-run variance.

 

[ataraksea]

I do see some noticeable improvements on some scenes, but the amount of Heap errors im getting its not worth using this.

The most likely reason for the heap errors you're getting when using this is because of the additional system memory usage compared to stock VAM. I've seen anywhere between 15%-35% increase in total system memory usage in my own testing. In general, this increased memory allocation is no big deal, after all unused system memory is essentially just going to waste. However, for those who might not have much system memory to begin with or for those that have what might be charitably described as a metric fuckton of VARs, a category that I myself fall into, it can very quickly exceed one's combined physical and virtual memory resulting in everyone's favorite heap CTD.

There are multiple ways to potentially address this, with the simplest obviously being just not installing this patch. What I recommend though is installing one of two different plugins, and really I recommend using one of these regardless of whether you intend to install this patch or not. They both do more or less the same thing, which is to only load VARs into VAM when you actually need them, and thus both have the potential to dramatically increase performance when you have a significant number of VARs installed. The first is a free plugin, var browser, and honestly it is a very solid choice. It has its own built-in browser system with which you interact with your unloaded VARs that is roughly on par with the browser built into VAM. With that said, if you are willing to spend a few bucks, I highly recommend the fantastic BrowserAssist instead, which actually just recently introduced its own functionality comparable to var browser's, but with the added bonus that you can interact with your unloaded VARs with what is IMHO a much superior browser to VAM's default. But yeah, hopefully this post will be of assistance to others in the future.

 

[gghhoosstt123]

The most likely reason for the heap errors you're getting when using this is because of the additional system memory usage compared to stock VAM. I've seen anywhere between 15%-35% increase in total system memory usage in my own testing. In general, this increased memory allocation is no big deal, after all unused system memory is essentially just going to waste. However, for those who might not have much system memory to begin with or for those that have what might be charitably described as a metric fuckton of VARs, a category that I myself fall into, it can very quickly exceed one's combined physical and virtual memory resulting in everyone's favorite heap CTD.

There are multiple ways to potentially address this, with the simplest obviously being just not installing this patch. What I recommend though is installing one of two different plugins, and really I recommend using one of these regardless of whether you intend to install this patch or not. They both do more or less the same thing, which is to only load VARs into VAM when you actually need them, and thus both have the potential to dramatically increase performance when you have a significant number of VARs installed. The first is a free plugin, var browser, and honestly it is a very solid choice. It has its own built-in browser system with which you interact with your unloaded VARs that is roughly on par with the browser built into VAM. With that said, if you are willing to spend a few bucks, I highly recommend the fantastic BrowserAssist instead, which actually just recently introduced its own functionality comparable to var browser's, but with the added bonus that you can interact with your unloaded VARs with what is IMHO a much superior browser to VAM's default. But yeah, hopefully this post will be of assistance to others in the future.

Man i wish var browser was not abondoned, its really underated and is by far the best when it comes down to var management and hub browser download ways and stuff for free. Wish someone else expand on it in future like other plugins that got abandoned as well.

 

[Seraphim]

Man i wish var browser was not abondoned, its really underated and is by far the best when it comes down to var management and hub browser download ways and stuff for free. Wish someone else expand on it in future like other plugins that got abandoned as well.

Someone else is expanding on it, literally explained who in the post you read lol. BrowserAssist beta plugin by JayJayWon now has VarManager integrated into it. So it disables or displaces vars until you load them. Currently updating it weekly.

 

[Seraphim]

Chipping away at that physics time. Dont really know what im doing when it comes to boot file settings. and for some reason i can never even get to 6200mt on any of my ram no matter what cpu. skill problems lol

Just the basic PBO, Curve -30, Tightened ram timings, and cpu clock multiplier of 102mhz

 

[gghhoosstt123]

Someone else is expanding on it, literally explained who in the post you read lol. BrowserAssist beta plugin by JayJayWon now has VarManager integrated into it. So it disables or displaces vars until you load them. Currently updating it weekly.

i mentioned best for free. i know browser assist but its paid. i doubt the var function will be availble on free version.

 

[Da_Pig]

I do see some noticeable improvements on some scenes, but the amount of Heap errors im getting its not worth using this.

I would suggest version 12 - Never moved to 13 since I read about the heap errors and was waiting for a newer one. The gains are real with v12