CTD and Performance patch ENBoost (by Boris Vorontsov)

[phazer11]

Very true, they have joined forces over at the ENB forums talking about the weird voodoo magic that needs to be performed to solve the issues with threading.

I think Boris got a nice refreshing breath that there is someone else he can actually talk with on his level!

 

So is there a forth member? It's all they need to complete the four horsemen. Memory, Threading, Performance, and Stability.

[WilliamImm]

Heh, I may actually want to speak with Boris and help him with evil low-level engine hacking.

[MontyMM]

I don't have a STEP setup right now (I need to redownload afresh), but I did some simple measurements with VMMap at a few locations. In every case, the detailed metrics show a reduction of hundreds of MB of in use by the Skyrim process when ENBBoost is active. This memory decrease is real, IMO, and not merely hidden as in the phony toy apps.

 

Whether this is a stable solution itself, and how far these new limits can be pushed, I can't say. But I can say that I beleive it is doing what it claims, and I look forward to pushing it with a heavy texture load to see how it shakes out. I'll put up some figures, and I think we're going to like them.

[Nearox]

Has anyone tried 0.215 (or up) with the new transparency AA feature?

[DoYouEvenModBro]

Best comment from the Nexus page so far:

 

 

 

 

 

 

"Nice going guys.

 

It f***in bothers me that so many excellent mod creators and people who generally advance the tech of this game are forced into hiding cause f***in retarded users who want endless help.

 

Eat s*** and die every last one of you and you know who you are."

[alt3rn1ty]

Your ENBLocal.ini guide has gone out of date quite quickly recently

https://wiki.step-project.com/Guide:ENB#tab=Editing_Enblocal_INI

 

V0.217 of ENB ..

FixPhysics= Gone

 

There was a problem with enabling RemoveBlur=true - If you were only using ENBoost ( with UsePatchSpeedhackWithoutGraphics=true ) - That has now been fixed

 

And there have been approximately 3 re-uploads of v0.217

 

The fix section now includes the following ..

 

[FIX]

FixGameBugs=true

FixParallaxBugs=true

FixAliasedTextures=true

IgnoreLoadingScreen=false

IgnoreInventory=true

FixSsaoWaterTransparency=true

FixSsaoHairTransparency=true

FixTintGamma=true

RemoveBlur=true

FixSubSurfaceScattering=true

 

I have no in depth knowledge of those new settings.

 

--------------------------------------

 

 

Can anyone else corroborate something I have found experimenting with ENBoost ..

 

My machine Specs Minimum requirement for this game -

Win 7 x32, Core 2 duo 2.2 ghz, NVidia 8600m GS 512mb VRAM, 4gb system RAM

 

Three settings of interest are these ..

 

[MEMORY]

DisablePreloadToVRAM=true

ReservedMemorySizeMb=256

VideoMemorySizeMb=0

 

I know by everything I have seen on these settings that I should set the last one to = VRAM on graphics card, and I saw the equation to raise it further.

 

However I find having it slightly less than the cards VRAM max works better for me.

On my machine, I get far better performance if I have them set ..

 

DisablePreloadToVRAM=false

ReservedMemorySizeMb=256

VideoMemorySizeMb=350

 

So the game still preloads, it has a cache of system ram to supplement VRAM, and the allocated VRAM setting for ENBoost is less than the graphics cards max ( the reason I tried this was that it didn't make sense to me letting ENB take charge of all the VRAM, if windows also needs a slice of that pie up to circa 150mb ) .. To my surprise it works well.

[EssArrBee]

I am aware of this, and also aware that the ENB Series INI section is really, really out of date. I've been trying to find time to read up on that section, but of course Boris keeps adding new things and now he's trying to figure out how to correctly implement SSS on people, so it will only get more out of date. It is really out of date about a week after updating with the speed of development. Kinda wish Boris would go back to GTA or The Witcher for a couple weeks.

 

I'll probably add your findings to the troubleshoot section for lower end systems (GS8600m dude wtf?).

 

EDIT: Okay, I just went ahead and added a the AA section and then copy pasted the FIX stuff in and will update with more info when I get a chance maybe later today. Thanks for reminding me alt3n1ty!

[alt3rn1ty]

I'll probably add your findings to the troubleshoot section for lower end systems (GS8600m dude wtf?).

:) We have a much better Desktop, but my personal machine is a slightly dated laptop .. Which was the inspiration for my Vanilla Reduced Textures ( before I upgraded the graphics daughterboard to have 512mb vram instead of its old 256mb spec )

[alt3rn1ty]

Can anyone else corroborate something I have found experimenting with ENBoost ..

 

My machine Specs Minimum requirement for this game -

Win 7 x32, Core 2 duo 2.2 ghz, NVidia 8600m GS 512mb VRAM, 4gb system RAM

 

Three settings of interest are these ..

 

[MEMORY]

DisablePreloadToVRAM=true

ReservedMemorySizeMb=256

VideoMemorySizeMb=0

 

I know by everything I have seen on these settings that I should set the last one to = VRAM on graphics card, and I saw the equation to raise it further.

 

However I find having it slightly less than the cards VRAM max works better for me.

On my machine, I get far better performance if I have them set ..

 

DisablePreloadToVRAM=false

ReservedMemorySizeMb=256

VideoMemorySizeMb=350

 

So the game still preloads, it has a cache of system ram to supplement VRAM, and the allocated VRAM setting for ENBoost is less than the graphics cards max ( the reason I tried this was that it didn't make sense to me letting ENB take charge of all the VRAM, if windows also needs a slice of that pie up to circa 150mb ) .. To my surprise it works well.

And something else to corroborate - But this time not necessarily for low end machines :

 

ExpandSystemMemoryX64=false

 

Since starting to use this there has always been a slight lag which I could not explain, and my good fps would indicate I should not be 'feeling' any lag.

 

I just tried this setting as false .. And I am not ashamed to use the expression O M G

 

I could not believe the difference this made for performance. Not performance in statistics, but performance in the feel of the game, it feels as smooth as butter.

 

ENBoost for me has never been about stopping CTDs ( I dont get them ) - But it obviously stands to reason I should be getting better performance from using it ..

 

Now I do. Like I have never experienced before.

 

So shocked by the difference, I wondered if it would also make a difference on our desktop

 

Desktop = Win 7 x64 with 1024mb VRAM on a much better NVidia card and more capable CPU etc.

 

I set it to false on that machine and its running at a constant 60 FPS ( ie that machine is restricted by VSync to the screen refresh rate - And now the game is constantly hitting that ceiling, no dips ).

But forget the FPS, the difference in perceived performance is the same on that machine aswell.

 

Swing your mouse around with the mouse sensitivity set quite high so the world spins around you fast .. No slight pauses at all.

[EssArrBee]

When I can tell under no circumstance should you mess with vsync either in skyrim.ini, skyrimprefs.ini, and enblocal.ini. Physics gets crazy weird over 60 FPS.

 

Did you use the utility that was provided by Phinix? I've also linked to it on our wiki in the install section I believe. That is pretty much the best bet for getting the [MEMORY] section correct in enblocal.ini. I know lots of different things come into play like GPU architecture, drivers, system RAM, VRAM, prayer to Cthulhu... so it can be a bit of a pain to test every configuration.

 

This line: ExpandSystemMemoryX64=false should be set to false on x86-32 systems, even though it can be set to true without affecting most PCs. Probably has little effect on more powerful systems though, and would probably not even matter on your desktop either way. I'd bet you get the same performance either way.

 

I'm surprised you use ENB on your laptop, I'm guessing that you set UsePatchSpeedhackWithoutGraphics=true when on that thing. Can't see you using SSAO or Skylighting.

[alt3rn1ty]

This topic is about ENBoost isnt it ?, not ENB in its traditional use.

[EssArrBee]

Well, yes, but ENB in its traditional sense comes with ENBoost active and ENBoost without the graphics still requires the d3d9.dll. As long as the posts are related mostly to the memory performance of ENB it's all good.

[alt3rn1ty]

When I can tell under no circumstance should you mess with vsync either in skyrim.ini' date=' skyrimprefs.ini, and enblocal.ini. Physics gets crazy weird over 60 FPS.[/quote']

I dont mess with VSync - Nor did I say I was intending to.

 

Did you use the utility that was provided by Phinix? I've also linked to it on our wiki in the install section I believe. That is pretty much the best bet for getting the [MEMORY] section correct in enblocal.ini. I know lots of different things come into play like GPU architecture, drivers, system RAM, VRAM, prayer to Cthulhu... so it can be a bit of a pain to test every configuration.

I have had a look at that, its very useful I guess for ENB users :

But not necessary if you only use ENBoost ( The assorted ini's per machine spec' in the ENBoost zip have pretty much the same ini setups as you would gain from using Phinix tool for each use case : ENBoost comes with ATI/AMD/NVidia folders, which have further folders separated into different graphics card VRAM sizes, and a specific ini within each of those which have Boris recommended setup for those machines )

 

This line: ExpandSystemMemoryX64=false should be set to false on x86-32 systems, even though it can be set to true without affecting most PCs. Probably has little effect on more powerful systems though, and would probably not even matter on your desktop either way. I'd bet you get the same performance either way.

 

Now see this "should be set as false on x86" is not mentioned anywhere so far, it is recommended in all the ENBoost ini's as being True

 

Its recommended if you choose the 32 bit route on Phinix tool

 

And on the wiki for this subject "Can generally be left true even for 32-bit systems. If using a 32-bit system and having problems test as false." ..

But .. In Boris Readme which comes with ENBoost "3) If stuttering bother too much, edit enblocal.ini file vriables ExpandSystemMemoryX64, ReduceSystemMemoryUsage(especially this one), DisableDriverMemoryManager."

The emphasis is put on changing ReduceSystemMemoryUsage(especially this one)

 

So users are kind of led to look at ReduceSystemMemoryUsage instead of ExpandSystemMemoryx64

 

For anyone not used to following ENB developments, but swarming to the new CTD preventing / performance enhancing ENBoost : These details are not entirely clear.

 

I'm surprised you use ENB on your laptop, I'm guessing that you set UsePatchSpeedhackWithoutGraphics=true when on that thing. Can't see you using SSAO or Skylighting.

I dont use ENB, I'm talking about ENBoost being used as intended with UsePatchSpeedhackWithoutGraphics=true

 

I guess the confusion as to exactly what we are talking about is understandable, given that even the author was scratching his head and adamantly swore by RemoveBlur=true working as intended : Until he realised that it does if you are using ENB graphics, but at the time for ENBoost users it was CTD'ing their machines. Fixed since, but yeah, even the author gets confused between full ENB users and ENBoost users :)

[alt3rn1ty]

All of the above asside, I think a point I made has been overlooked

 

I also tested ExpandSystemMemoryx64=false on two of our x64 bit machines

 

Which also performed far better using ENB binaries v0.217 and that setting as false.

 

Its not just about my low x86 machine.

 

Can anyone else corroborate something I have found experimenting with ENBoost ..

 

My machine Specs Minimum requirement for this game -

Win 7 x32, Core 2 duo 2.2 ghz, NVidia 8600m GS 512mb VRAM, 4gb system RAM

 

Three settings of interest are these ..

 

[MEMORY]

DisablePreloadToVRAM=true

ReservedMemorySizeMb=256

VideoMemorySizeMb=0

 

I know by everything I have seen on these settings that I should set the last one to = VRAM on graphics card, and I saw the equation to raise it further.

 

However I find having it slightly less than the cards VRAM max works better for me.

On my machine, I get far better performance if I have them set ..

 

DisablePreloadToVRAM=false

ReservedMemorySizeMb=256

VideoMemorySizeMb=350

 

So the game still preloads, it has a cache of system ram to supplement VRAM, and the allocated VRAM setting for ENBoost is less than the graphics cards max ( the reason I tried this was that it didn't make sense to me letting ENB take charge of all the VRAM, if windows also needs a slice of that pie up to circa 150mb ) .. To my surprise it works well.

And something else to corroborate - But this time not necessarily for low end machines :

 

ExpandSystemMemoryX64=false

 

Since starting to use this there has always been a slight lag which I could not explain, and my good fps would indicate I should not be 'feeling' any lag.

 

I just tried this setting as false .. And I am not ashamed to use the expression O M G

 

I could not believe the difference this made for performance. Not performance in statistics, but performance in the feel of the game, it feels as smooth as butter.

 

ENBoost for me has never been about stopping CTDs ( I dont get them ) - But it obviously stands to reason I should be getting better performance from using it ..

 

Now I do. Like I have never experienced before.

 

So shocked by the difference, I wondered if it would also make a difference on our desktop

 

Desktop = Win 7 x64 with 1024mb VRAM on a much better NVidia card and more capable CPU etc.

 

I set it to false on that machine and its running at a constant 60 FPS ( ie that machine is restricted by VSync to the screen refresh rate - And now the game is constantly hitting that ceiling, no dips ).

But forget the FPS, the difference in perceived performance is the same on that machine aswell.

 

Swing your mouse around with the mouse sensitivity set quite high so the world spins around you fast .. No slight pauses at all.

[Aiyen]

You can make all the general guidelines you want, people still need to adjust every setting for their own system.

If you find one of the parameters work nicely for you even though someone else says they should not then just too bad for them.

 

The main issue many people have is that its not just plug and play... they actually have to think and trial and error a little bit themselves, to learn what their own system requires, and can offer.