Plugins + Scripts CPU Performance Patch v2.0

[MiSiv]

MiSiv submitted a new resource:

CPU Performance Patch v2.0 - Repaired and security-restored CPU performance patch

An updated version of the CPU Performance Patch for Virt-A-Mate 1.22.0.13

Included - everything is set up to work together:

• Assembly-CSharp.dll and SkinMeshPartDLL.dll, with the v2.0 fixes
• 3x MAX_HEAP_SECTS mono.dll patch
• NativeGCPatcher, updated to 3.1 with cold-cache startup fix
• SkinMeshPartDLL.ini and boot.config...

Read more about this resource...

 

[Gabberjaw]

Real shame it needs bepinex while the original updated by Evo, doesn't.

 

[MiSiv]

Real shame it needs bepinex while the original updated by Evo, doesn't.

It’s not required. Only NativeGCPatcher requires BepInEx. This is mentioned in the post
You can use the patch itself without NativeGCPatcher or BepInEx

 

[Anand]

Hey. Let me loosely repeat my so-called "review" - Thank you for continuing to further optimize the performance of VAM 1 !!! Very glad that you're on the job.

Quick question: as for my critical must-have mods/plugins which rely on BepinEx, Var Browser is by far the most important. Did you by any chance test your solution alongside VB?

Second question, you and I crossed paths before re: the plugin from DiorBear which apparently parallelizes texture loading. I surmise that your solution completely supersedes his solution and that I can completely deinstall it?

 

[MiSiv]

Hey. Let me loosely repeat my so-called "review" - Thank you for continuing to further optimize the performance of VAM 1 !!! Very glad that you're on the job.

Quick question: as for my critical must-have mods/plugins which rely on BepinEx, Var Browser is by far the most important. Did you by any chance test your solution alongside VB?

Second question, you and I crossed paths before re: the plugin from DiorBear which apparently parallelizes texture loading. I surmise that your solution completely supersedes his solution and that I can completely deinstall it?

Hey Anand. I don't use Var Browser or any similar solution. My way of dealing with this is to keep my AddonPackages folder strictly organized, clean every single var of duplicates and junk before adding it, and keep unused vars outside of VaM. So I can't really comment on that.

This version 2.0 only adds/fixes what I listed in the post.
I'm still working on 3.0, and that's where I'll add everything we discussed earlier.

As for DriorBear's version, it was a complete mess. Most things either only work partially or don't work at all, not to mention the complete lack of any security. I don't recommend using it at all.

 

[tekomonakama]

I love this plugin, but I don't understand why I can't import clothes from Daz to VaM when I install it; I always end up getting a warning about a morph-related error.

 

[MiSiv]

I love this plugin, but I don't understand why I can't import clothes from Daz to VaM when I install it; I always end up getting a warning about a morph-related error.

Could you send me the exact error message or a screenshot of it? I’ll look into it

 

[Anand]

Hey Anand. I don't use Var Browser or any similar solution. My way of dealing with this is to keep my AddonPackages folder strictly organized, clean every single var of duplicates and junk before adding it, and keep unused vars outside of VaM. So I can't really comment on that.

This version 2.0 only adds/fixes what I listed in the post.
I'm still working on 3.0, and that's where I'll add everything we discussed earlier.

As for DriorBear's version, it was a complete mess. Most things either only work partially or don't work at all, not to mention the complete lack of any security. I don't recommend using it at all.

Thanks dood. I'll get rid of DiorBear. Which then leads me to JayJayWon. I've been using his BrowserAssist for friggin forever because its import function is top notch. Nothing else touches its ease of use. (BTW I do NOT use his VAR management at all - I find it requiring too much forethought and planning vs VB which I'll address below). DiorBear's writeup seems to imply that JayJayWon's code was inefficient and caused problems. When I begrudgingly uninstalled BrowserAssist, and I did notice significant faster loading times with DiorBear. So my question to you is: is it safe to go back to BrowserAssist (minus his VAR management which I'm assuming you don't need)?

As for VB, it just works for me. I have a "Core" dir containing "must have" plugins and a few favorite items of clothing. Everything else gets stored in AllPackages directory which is not recognized by VAM. VAM loads lightning fast. As I load scenes to play with, VB generally does a good job of locating and loading the dependencies into AddonPackages. My point is that I literally do NOT have to think about what I want in AddonPackages to load, and what to exclude. There is almost NOTHING in my AddonPackages dir besides "Core" VARs at startup time. Anything I need during gameplay can be accessed after load via VB.

Anyway, I don't want to come across as proselytizing VB. You do you. It's just that VB works really well for my use case which is why i wanted to know if you had tested it along side you patch. No worries. I'll check it out and report back - when I find some time.

Thanks again for moving the ball forward. There's still so much potential in VAM 1 to be unlocked (not to mention so much, too much content).

 

[Tomblack]

the original cpu performance patch gave me no performance increase on a 5700x3d, now lets see how this performs.

Edit1: Why is the affinity missing the first physical cpu core? Currently its 3,5,7,9,11,13,15 overall thats just seven cores.

 

[Gabberjaw]

Hey. Let me loosely repeat my so-called "review" - Thank you for continuing to further optimize the performance of VAM 1 !!! Very glad that you're on the job.

Quick question: as for my critical must-have mods/plugins which rely on BepinEx, Var Browser is by far the most important. Did you by any chance test your solution alongside VB?

Second question, you and I crossed paths before re: the plugin from DiorBear which apparently parallelizes texture loading. I surmise that your solution completely supersedes his solution and that I can completely deinstall it?

FYI, DiorBear was banned from the hub for plagiarizing plugins from HuntingSuccubus and Eosin. I wouldn't get involved with anything he makes.

 

[MiSiv]

Edit1: Why is the affinity missing the first physical cpu core? Currently its 3,5,7,9,11,13,15 overall thats just seven cores.

The affinity 3,5,7,9,11,13,15 selects one logical thread from each of seven physical cores and leaves the first core free for VaM’s main thread, other apps threads and windows. After a lot of testing, this configuration works best on my 5700X3D

 

[f896]

What would be the recommended settings for a 9800X3D?

 

[Eye9]

@MiSiv Could you elaborate a little on these two items? What is it that is being fixed, what is the "managed morph fallback" and "morph-split lookup"?

• Fixed native morph batch sizing and null morph-bank handling.
• Restored the vanilla managed morph fallback and morph-split lookup.

 

[MiSiv]

@MiSiv Could you elaborate a little on these two items? What is it that is being fixed, what is the "managed morph fallback" and "morph-split lookup"?

Sure. In the optimized morph code, complex morph formulas could generate more batch entries than the allocated array could hold, causing morph processing errors. The batch now expands when needed. I also fixed a null-reference case that could occur when a morph was copied before being assigned to a morph bank.
By “managed morph fallback” I mean VaM’s original threaded C# morph-processing path. Its implementation was missing, so I restored it.
“Morph-split lookup” is part of VaM’s morph-authoring tool. It finds the source morph and maps its affected vertices so VaM can create filtered or split morphs. That lookup was also restored.

 

[Eye9]

Sure. In the optimized morph code, complex morph formulas could generate more batch entries than the allocated array could hold, causing morph processing errors. The batch now expands when needed. I also fixed a null-reference case that could occur when a morph was copied before being assigned to a morph bank.
By “managed morph fallback” I mean VaM’s original threaded C# morph-processing path. Its implementation was missing, so I restored it.
“Morph-split lookup” is part of VaM’s morph-authoring tool. It finds the source morph and maps its affected vertices so VaM can create filtered or split morphs. That lookup was also restored.

Ah I see, thanks! So these are straight-up bugfixes for the original performance patch but shouldn't affect performance during "normal" use right? I'm curious where the two latter morph issues would have manifested, I never encountered issues afair when e.g. bringing in custom .dsf morph files.

 

[Makimax]

I tried the various patch versions; despite them working correctly, I didn't see *any* improvement on my laptop (Intel 12700H with 6 P-cores and 8 E-cores, and an RTX 3070 Ti Mobile 150W). I'm hoping this one will boost performance. Do you have any suggestions for the configuration file? Here is my current setup:
[threads]
computeColliders=8
skinmeshPart=8
applyMorphs=8
skinmeshPartMaxPerChar=4
applyMorphMaxPerChar=4
affinity=1,3,5,7,9,11
engineAffinity=1,3

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

[profiler]
enabled=0

 

[MiSiv]

Ah I see, thanks! So these are straight-up bugfixes for the original performance patch but shouldn't affect performance during "normal" use right? I'm curious where the two latter morph issues would have manifested, I never encountered issues afair when e.g. bringing in custom .dsf morph files.

Yes, exactly. During normal use, the main native morph path stays unchanged, so these fixes shouldn’t affect FPS. The batch resize only activates when a complex morph-formula chain exceeds the original capacity, and the null check has negligible cost.
The managed path is used by DAZMorphBank instances running their own threaded updates. Morph Split is an authoring tool that copies a source morph and filters its vertex deltas.
Custom .dsf import uses VaM’s regular runtime morph-import path, so it normally wouldn’t trigger either of those two issues. That’s why you likely never encountered them.