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)

Incredibly based, but I insist that you should maybe ask Meshed if he doesn't want the work you did become an actual update. For free, if you wish, but I think you deserve at least a couple bucks since you did him significant optimization work.
he has his hands full with vam2 and you can always just literally install this patch, there wont be any big vam1 updates anymore. There is no reason to merge my changes into vam1.
 
Bros, I think I found the VR issue:

Exactly same scene, same settings, just different resolution in VR and obviously 2 eyes.
2D:
Benchmark complete. Avg. tot time: 5.55 Avg. physics time: 3.27 Avg. physics time (only fixedUpdate frames): 5.72 Avg. internal physics time: 0.88 Avg. scripts time: 1.45 Avg. render time: 0.83 Avg. wait time: 0.04 Avg. FPS: 227.06
VR:
Benchmark complete. Avg. tot time: 13.82 Avg. physics time: 8.76 Avg. physics time (only fixedUpdate frames): 8.77 Avg. internal physics time: 1.70 Avg. scripts time: 3.69 Avg. render time: 1.37 Avg. wait time: 0.00 Avg. FPS: 62.19

As you can see, the render time increased from 0.83ms to 1.37ms, a 0.54ms increase, pretty much what you would expect when rendering two eyes. Literally everything else increased by pretty much exactly double, although it has nothing to do with rendering. Physics doesnt need to run twice if you render two cameras (eyes). My FPS in VR should've been 164fps...
I will investigate.
 
Lots of weird stuff happens with framerate in VR - on my 13900K/4090 rig, getting very close to thick, simmed hair has little effect on framerate as long as I am on desktop, but try to do the same thing in VR and all of a sudden even my mighty rig drops to single digit FPS.
 
questions than it answers.

Again, this isn't a moderator request, just

Lots of weird stuff happens with framerate in VR - on my 13900K/4090 rig, getting very close to thick, simmed hair has little effect on framerate as long as I am on desktop, but try to do the same thing in VR and all of a sudden even my mighty rig drops to single digit FPS.
me too 13700K/4090 Rig
 
yep, I figured out the descrpancy in fps. I was getting with the same scene 50fps in desktop, 30 in VR.

weird. same settings.
you ofc have to take in mind that VR FPS != Non-VR FPS. VR runtimes always enforce a Vsync to reduce stuttering. Your FPS average is no longer the average between all frames, but the frames were prolonged to 1000/90. This means the "max 1%" is now 90fps (the HMD refreshrate) and your slowest frames now weight more in the average.
HOWEVER we see an increase of all timings even when we have constant 90fps and in my profiling I see that literally every function running in C# somehow took longer, but the code in my native patch still processed the same data in the same time. So unity is doing something to CoRoutines, like preemptying the threads, but only when they are in C#.

When running in VR, everything allocates about 3x as much memory while running in C#. I believe something (steamvr?) is constantly filling the garbage collector in a background thread and it shows up everywhere.

NonVR
1707628857947.png


SteamVR
1707628888550.png


Not only did the garbage grew fast while executing the first method, the second method should never allocate anything and yet in VR the garbage grows.
Methods which do not need the C# heap while they run did not slow down. Methods which do use the C# heap are slowed down across the whole application, because they wait for the mysterious trash thread to unlock the heap.
Folks, I might actually solve this.
This is 100% the performance issue in VR
 
Last edited:
我发现只有 4 个核心在工作。我使用的默认配置。fps 较低。
 

Attachments

  • 屏幕截图(1).png
    屏幕截图(1).png
    45.6 KB · Views: 0
Regarding hair in VR. I usually reduce the hair multiplier and curve density (each at least <16) in the hair options. Sometimes I make the hair thicker (don't recall the option name) to compensate for fewer hair. Also it seems hair + light with shadow enabled is a real fps eater, so I in addition often disable shadows on lights.
 
I just ran a long vr session in a clean cam install, with patch 13, and the latest patreon version of everlasters naturalis, in a modified version of simpleride 3 by c&g. It's a riding cowgirl scene with a lot of movement. While performance was stellar, it seems there is some very weird stuff going on with physics. With or without naturalis breast's seem substantially softer, especially when small. The larger they get the more normal the physics seems. Also after Bout 30 minutes of the scene running, suddenly the girl is bouncing slightly on her own, without any animations running. I run this scene often, and these issues only showed up with your patch. I didn't try 10 or 11 in vr, so I'll try those builds.
 
Last edited:
I just ran a long vr session in a clean cam install, with patch 13, and the latest patreon version of everlasters naturalis, in a modified version of simpleride 3 by c&g. It's a riding cowgirl scene with a lot of movement. While performance was stellar, it seems there is some very weird stuff going on with physics. With or without naturalis breast's seem substantially softer, especially when small. The larger they get the more normal the physics seems. Also after Bout 30 minutes of the scene running, suddenly the girl is bouncing slightly on her own, without any animations running. I run this scene often, and these issues only showed up with your patch. I didn't try 11 or 22 in vr, so I'll try those builds.
did you increase physics rate? breasts become very soft for some reason if physics runs often, even in vanilla.
 
did you increase physics rate? breasts become very soft for some reason if physics runs often, even in vanilla.

There is a setting called Physics Update Cap. This setting specifies the maximum number of Physics Updates that can run per rendered frame. If your FPS is low enough that this cap gets hit, you could experience time slowing down, which will make everything look slo-mo. This is just an unfortunate side effect of physics running at a fixed frame rate and being independent of the rendered frames. Try setting to 3 to minimize that possibility, but note that it could lower your FPS because each physics update takes a lot of time and up to 3 could happen per rendered frame. This could happen if you have physics rate set very high and/or your rendered FPS is very low.

I appreciate everything you are doing here, and I'm glad to see you discovered the Physx single thread bottleneck (which is a bit better in newer Unity versions but it still sucks - I'll be doing custom skin physics in VaM2 for this reason). I also glad you posted those charts of how the character threads timing works. The goal for VaM1 was to hit 90FPS for VR usage. I realize with heavy physics it often does not hit that unless you have a very good CPU/GPU and are not running a scene with lots of models all with soft-body physics on. It was a challenge. The character threads code was optimized just enough to try to hit this 90FPS so as not to be the bottleneck. The skinning system is very inefficient as is the morph code. It is great you addressed both of those. When I developed this I didn't see much of a point trying to hit a max FPS above 90 since I was targeting VR and that was the sweet spot. The ultimate bottleneck is Physx on physics heavy scenes and there isn't any way around that. That all said, I am still very glad you looked into this and found some amazing fixes just sitting there for many/most users. I would love to roll this back into official release at some point if you are willing and I can find some time in between VaM2 work. That might be tough. I would definitely compensate you if we manage go this route. If you are interested in making some $$$, I could even give you access to the VaM github repos so we can add this in an easier-to-review manner. I would want to review everything just to make sure nothing is getting broken. DM me if you want to go this route.

Thank you!
 
did you increase physics rate? breasts become very soft for some reason if physics runs often, even in vanilla.
We'll I have phys rate set to auto, which is 90hz, and update cap set to 3. Same settings I usually run. I'll make a couple recordings to show the difference I'm seeing with patched vs non-patched. Read through meshed's response, and while the scene did eventually start to bog down, I was pretty steady at 90 fps, with a matching phys rate and update cap at 3, but even small chested model had breast movement like they were soft and heavy. I'll continue to to investigate, don't want to give up these additional frames.

Running a quest 3 via virtual desktop, bypassing steam and oculus runtimes, with passthrough which limits the max refresh rate to 90.
 
@turtlebackgoofy
I know you mentioned: "Also loading cloths/hair from every var no longer loads cloths/hair from every var for each cloth/hair loaded, which speeds up scene loading when you have a lot of vars installed."

but dude, yesterday I run VaM (with 7k+ vars) in VR and my scenes were loading like 70% FASTER (didn't measure it, just my feeling).
This is amazing. I could load scenes in like 10-15s where previously it would take almost one minute, sooo noticeable difference.
Again, great work!
 
We'll I have phys rate set to auto, which is 90hz, and update cap set to 3. Same settings I usually run. I'll make a couple recordings to show the difference I'm seeing with patched vs non-patched. Read through meshed's response, and while the scene did eventually start to bog down, I was pretty steady at 90 fps, with a matching phys rate and update cap at 3, but even small chested model had breast movement like they were soft and heavy. I'll continue to to investigate, don't want to give up these additional frames.

Running a quest 3 via virtual desktop, bypassing steam and oculus runtimes, with passthrough which limits the max refresh rate to 90.
Well for small chest you might wanna lower the mass and crank up the spring, otherwise they will play you the song of their people.
This issue isn't coming from this cpu mod.

Edit: I also think that JointCorrect and ShakeIt does not like whats going on here with those 9999999 automated morphs being applied.
 
Well for small chest you might wanna lower the mass and crank up the spring, otherwise they will play you the song of their people.
This issue isn't coming from this cpu mod.

Edit: I also think that JointCorrect and ShakeIt does not like whats going on here with those 9999999 automated morphs being applied.
I've been running this heavily modified scene for months, at least once a week, in vr, with literally hundreds of different models of various shapes and sizes, without this issue. Saying it's not coming from this mod seems a bit premature, as he has stated he made changes in the last patch that directly affects how morphs in things like naturalis load, and there have already been morph bugs in his previous patches, so it's not some wild idea that something is messed up.
 
I've been running this heavily modified scene for months, at least once a week, in vr, with literally hundreds of different models of various shapes and sizes, without this issue. Saying it's not coming from this mod seems a bit premature, as he has stated he made changes in the last patch that directly affects how morphs in things like naturalis load, and there have already been morph bugs in his previous patches, so it's not some wild idea that something is messed up.
correct, it is very much possible that under some loading circumstances a morph that makes breasts less shaky went missing
 
I've been running this heavily modified scene for months, at least once a week, in vr, with literally hundreds of different models of various shapes and sizes, without this issue. Saying it's not coming from this mod seems a bit premature, as he has stated he made changes in the last patch that directly affects how morphs in things like naturalis load, and there have already been morph bugs in his previous patches, so it's not some wild idea that something is messed up.
My bad then, I was only speaking out of my own experience. I had those floppy small breasts way before this was introduced, always happened with default settings.
 
I have a AMD 5800X chip. Do I modify the [threadsVR] to match [threads} or leave them as is? [threads] matches the 5800X settings shown on the overview page. Below is the settings in the config file. Thanks for doing this.

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

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

[profiler]
enabled=0
 
I think I found some workaround for VR for now:

Same settings as for Non-VR and doing no workaround:
all.png

Same, but banishing all processes except vam into a different CCD, so VaM runs exclusively on a CCD, while ignoring SMT cores:
banishing_all_processes.png


Also reserving the two fastest cores for the unity engine (another tweak I will release soon)
Benchmark-20240211-222620.png


The script (needs to be run in powershell and as admin after vam and steamvr and everything has finished loading)
Code:
# elevate privileges if we are not running as Administrator, so we can set affinity of Windows owned processes
# source: http://superuser.com/questions/108207/how-to-run-a-powershell-script-as-administrator

param([switch]$Elevated)

function Test-Admin {
    $currentUser = New-Object Security.Principal.WindowsPrincipal $([Security.Principal.WindowsIdentity]::GetCurrent())
    $currentUser.IsInRole([Security.Principal.WindowsBuiltinRole]::Administrator)
}

if ((Test-Admin) -eq $false)  {
    if ($elevated) {
        'tried to elevate to full privileges, did not work, aborting'
    } else {
        'running my self again with full privileges'
        Start-Process powershell.exe -Verb RunAs -ArgumentList ('-executionpolicy bypass -noprofile -file "{0}" -elevated' -f ($myinvocation.MyCommand.Definition))
    }
    exit
}
'running with full privileges'

# binary: 11111111111111110000000000000000
# means set all processes to core 17-32

$affinity = 4294901760
'setting all processes to affinity: '+$affinity
'processes unable to set affinity of: '

$allProcesses = Get-Process | Where {$_.ProcessName -NotLike "vam"}
foreach ($process in $allProcesses) {
    try {
        'process: ' + $process
        $process.ProcessorAffinity = $affinity
    }
    catch {
        $process
    }
}

It appears for AMD atleast, that giving VaM exclusive access to a set of cores running on a CCD and banishing all other processes to other cores AND giving the unity main thread the fastest two cores for itself, has the best outcome in VR.

Now I am passing almost all benchmarks for smooth VR:
Benchmark-20240211-224358.png
 
Last edited:
correct, it is very much possible that under some loading circumstances a morph that makes breasts less shaky went missing
Hey so I've spent the last couple hours testing different versions, and now I can't get the problem to repeat after going back to the same install and scene and patch version 12. So it seems to have resolved itself. I did restart the PC and clear VAM cache. Oddly enough, I'm not seeing quite the same fps gains now. Its a 2 person (male and female) scene, in VR, man is laying down, POV, female in cowgirl position, and frequent dips into the 60 fps range when shes riding hard. Minimal hair sim too. checked powershell and the dll is loaded. 4090, and 5800X3D, no issues keeping temps down, GPU never above 60, CPU never above 70. Same scene in desktop mode was averaging over 200fps

running the recommended ini settings for my 5800X3D,
[threads]
computeColliders=8
skinmeshPart=8
applyMorphs=8
skinmeshPartMaxPerChar=8
applyMorphMaxPerChar=8
affinity=1,3,5,7,9,11,13,15

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

[profiler]
enabled=0

I'm about to test your VR workaround. I'll let you know how that goes.
 
I think I found some workaround for VR for now:

Same settings as for Non-VR and doing no workaround:
View attachment 334157
Same, but banishing all processes except vam into a different CCD, so VaM runs exclusively on a CCD, while ignoring SMT cores:
View attachment 334158

The script (needs to be run in powershell and as admin after vam and steamvr and everything has finished loading)
Code:
# elevate privileges if we are not running as Administrator, so we can set affinity of Windows owned processes
# source: http://superuser.com/questions/108207/how-to-run-a-powershell-script-as-administrator

param([switch]$Elevated)

function Test-Admin {
    $currentUser = New-Object Security.Principal.WindowsPrincipal $([Security.Principal.WindowsIdentity]::GetCurrent())
    $currentUser.IsInRole([Security.Principal.WindowsBuiltinRole]::Administrator)
}

if ((Test-Admin) -eq $false)  {
    if ($elevated) {
        'tried to elevate to full privileges, did not work, aborting'
    } else {
        'running my self again with full privileges'
        Start-Process powershell.exe -Verb RunAs -ArgumentList ('-executionpolicy bypass -noprofile -file "{0}" -elevated' -f ($myinvocation.MyCommand.Definition))
    }
    exit
}
'running with full privileges'

# binary: 11111111111111110000000000000000
# means set all processes to core 17-32

$affinity = 4294901760
'setting all processes to affinity: '+$affinity
'processes unable to set affinity of: '

$allProcesses = Get-Process | Where {$_.ProcessName -NotLike "vam"}
foreach ($process in $allProcesses) {
    try {
        'process: ' + $process
        $process.ProcessorAffinity = $affinity
    }
    catch {
        $process
    }
}
does the script need modifying for my 5800X3D?
 
Back
Top Bottom