ACCEPTED ENBSeries (by Boris Vorontsov)

[keithinhanoi]

That was really good.  Thank you - the examples help a lot.  So why would someone want to set block 1 higher than this example?:

 

ExpandSystemMemoryX64=true

DefaultHeapInitialAllocMB=768

ScrapHeapSizeMB=256

 

What benefit could I gain by doing this instead?:

 

ExpandSystemMemoryX64=false

DefaultHeapInitialAllocMB=769 or higher

ScrapHeapSizeMB=256

 

In other words - Is it better to have the expanded X64 system memory or have more MB (greater than 768) in block 1?  If it's not better to have more than 768, does the game run worse or better with the use of expanded X64 system memory (set to true)?  My hunch would be that it's better.

 

Well, the only reason why anyone would need to set DefaultHeapInitialAllocMB higher than 768 is when the actual "Block 1" heap usage in-game reaches 512MB, and you get a CTD.

 

That's why Sheson's Memory Block Log tool is so very useful. The recommended value to start with for DefaultHeapInitialAllocMB is 768, but what you actually need to set it too depends heavily on the kinds of mods you have in your load order, and whether you've set uGrids above the default of 5.

 

In truth, a lot of people probably don't need to set DefaultHeapInitialAllocMB at 768, because if they used the Memory Block Log tool they would find the actual "Block 1" heap usage never even gets close to 512MB.

 

However, for people that have a lot of mods adding spawned creatures, NPCs, and other exterior worldspace elements - like myself - setting DefaultHeapInitialAllocMB to 768 is not enough. 

 

In my current play-though (on hold while I get ready to move back to the USA), I have had to bump up my DefaultHeapInitialAllocMB value no less than 8 times. What happened was I entered an area of the exterior worldspace where I had not gone before which pushed the "Block 1" heap usage to the same as I had allocated, and *boom*, I got a CTD. 

 

So, at this point, my DefaultHeapInitialAllocMB is set to 992, and if I turned on ExpandSystemMemoryX64, Skyrim would insta-crash on startup, unless I set ScrapHeapSizeMB to 256, of course.

 

Anyhow, in your case, it's pretty clear that you probably don't need to set DefaultHeapInitialAllocMB any higher than 768, but if you ever experience a crash that keeps happening in a certain area of the exterior worldspace, I'd recommend using the Memory Block Log tool to check if your "Block 1" heap usage is hitting the allocated limit.

 

You have the "luxury" of being able to choose if you want to set ExpandSystemMemoryX64 to true or false. If things are stable and working fine, then why change anything? 

[Greg]

Is there any real benefit to ExpandSystemMemoryX64=true? I've experimented with it both ways using STEP Extended and STEP Extended+REGS profiles and I don't notice a difference in memory allocation either way. I know setting it to true moves the blocks to the top of RAM and theoretically helps reduce fragmentation, but I've often wondered if this is really the case.

[Pretendeavor]

ExpandSystemMemoryX64=true

DefaultHeapInitialAllocMB=768

ScrapHeapSizeMB=256

Result --> No CTD / Stable

Before this gets generally accepted I would like to post my results here. I actually seem to get increased instability with these settings compared to the the same settings with ExpandSystemMemoryX64=false. I have a pretty heavy mod setup so regardless of the ExpandSystemMemoryX64 setting I expect to eventually either CTD, freeze or get an ILS with DefaultHeapInitialAllocMB of 768 because Block 1 will hit 512.

 

With ExpandSystemMemoryX64 set to true I think I DO get significantly more CTDs. I say 'significantly' here because I believe this is not coincidence anymore, although I obviously didn't use any statistical methods to completely rule out coincidence, nor did I test this 100 times in a row. I did use Memory Blocks Log and CTDs consistently happen before Block 1 reaches 512.

 

-

 

To confirm this I just ran a couple of tests again while writing this post, using the Alternate Start mod to start a new game and walk around in Solitude, Whiterun and the Solitude Docks. I have the SRLE and REGS packs installed, except switched out JK's Skyrim for Dawn of Skyrim. All resulted in CTDs, two of them right after a loading screen. The maximum values for Block 1 as reported by Memory Blocks Log were 472, 487 and 478 respectively. Note that none reach the maximum of 512 but are strangely close to each other.

 

With ExpandSystemMemoryX64 set to false the CTDs occur less often. Again I started in the locations mentioned above. The first resulted eventually in a frozen screen, the second and third in a CTD, but it took a lot longer. What's more, in all three occasion the maximum values for Block 1 (512) were reached.

 

What I'm trying to say here is that I feel that in the last three tests problems are purely caused by Block 1 hitting 512. It gets fixed by increasing DefaultHeapInitialAllocMB accordingly. In the first three tests however there seems to be something else going on, possibly the same strange interaction between the memory patch and the ExpandSystemMemoryX64 setting keith is speculating about. So his assumption that the interaction only occurs with a DefaultHeapInitialAllocMB setting > 768 might be false: to me it seems like it can also happen with a effective Block 1 allocation of 512.

 

-

While I admire your extensive knowledge about a lot of Skyrim-related technical issues, my system is not suffering from these memory constraints that you brought up as being issues when using ExpandSystemMemoryX64 set to true.

 

My SKSE.ini settings:

[Memory]

DefaultHeapInitialAllocMB=768

ScrapHeapSizeMB=256

 

In enblocal.ini I have ExpandSystemMemoryX64 set to true.  I rarely ever suffer from CTDs.  According to what you just said, if I set that enblocal.ini setting to true then I would have to set block 2 to 512.  I didn't have to do this.  I also don't get CTDs from having block 1 set to 768.

Based on the info keith provided us and my own experiences, I think it is informative to include a Memory Blocks log file when reporting this. The reason that some people don't experience any trouble with ExpandSystemMemoryX64=true while others do, even if both parties have determined that a DefaultHeapInitialAllocMB of 768 should be sufficient for their setup, might be because of a difference in how high their Block 1 values reach.

 

Lastly I also realize that I might be completely wrong on this. I would however like to see results of people that have their Block 1 values come close to 512 but not so close that they hit it, comparing ExpandSystemMemoryX64=true vs ExpandSystemMemoryX64=false.

Edited August 1, 2015 by Pretendeavor

[Greg]

I just reinstalled STEP Extended using 2k versions of the textures where applicable for most of the mods in the Conflicting Graphics section and regenerating the LOD textures at high resolution. After doing this I am getting a peak of 473/135 in Memory Blocks Log with ExpandSystemMemoryX64 set to true or false, and I'm not experiencing any crashes (knock on simulated wood) yet. I initially started from inside the Inn at Windhelm, walked to Solitude and walked around inside Solitude, and then walked to Whiterun and walked around inside Whiterun. It's completely possible that perhaps I'm not coming close enough to the max allocation to replicate your findings, though. I'm going to bump up Vividian Vanilla ENB to max resolution to see what affect this has on the block allocations.
 

[Memory]
DefaultHeapInitialAllocMB=768
ScrapHeapSizeMB=256

[kranazoli]

Hi,

 

https://forum.step-project.com/topic/2613-ctd-and-performance-patch-enboost-by-boris-vorontsov/?p=136772

 

I do not know which topic should have to choose.

 

Thanks!

Edited August 10, 2015 by kranazoli

[butterenough]

Thank you for your description of the ExpandSystemMemoryX64 True/False issue!

 

One thing that gets mentioned a lot is optimizing/not wasting memory by minimizing settings until you CTD or Memory Logs shows you are close/over the limit, which is understandable. But to clarify, for Sheson's patch, we are talking purely System Memory, right? So if I have 32GB of System Memory, setting the DefaultHeapInitialAllocMB and ScrapHeapSizeMB higher means the increased memory set aside for ScrapHeapSizeMB is "wasted", but if I have memory to waste, it might be worth it to jack DefaultHeapInitialAllocMB up? (My Memory Blocks log jumped to the 700s recently due to some heavy mod testing)

 

For Boris's ENBs/ExpandSystemMemoryX64 settings, I realize both System Memory and Video RAM are involved somehow-I have 6GB of VRAM, but according to what I am reading lately only 4094MB is accessible to me (under Windows 10/DX9).

[korun2015]

@Butterenough

 

Skyrim engine can use only 4 GB not more, even with 64 gb ram it won't use more than 4, Sheson patch allow to use all of it, then skyrim is a Dx9 game and if vram »2gb, your max video memory is 4094 / 4032 according to Boris'executabe minus W7 [-170] W8 [-350]

i set my ini to 512/1024 because of a few mod, but i've run a heavy modded Skyrim for long with only 256/768 without ctd and ExpandSystemMemoryX64 set to false (W7 pro)

[Nebulous112]

FYI, looks like Boris updated Skyrim ENB again. :-)  I found this out from Triptonite on the SR:LE thread.

 

 

v0.290 is now the latest; v0.279 is no longer available for download. (The next newest available after v0.290 is v0.262.)

 

From the ENB forum thread:

 

Graphic mod ENBSeries / patch ENBoost 0.290

Fixed bug of incorrect colors of some particle type. Added SDK to control parameters of shaders or configuration files.

What you can do with SDK? Create custom focusing areas and toggle dof when some game action occur; apply different effects according to things going on in the game; create director tool for making machinimas. It depends from you.

Included example can be tested by loading it via:

Code:

[PROXY]
EnableProxyLibrary=true
InitProxyFunctions=false
ProxyLibrary=ExamplePlugin.dll

but it must be SKSE or ScriptDragon actually to let users run other wrappers as proxy.

 

 

 

And here I figured Boris was done development on ENB for Skyrim. Nice!

[HypestHypeBoo]

Im doing the step:core guide and am wondering shouldve i ran enb.exe when i extracted it and the other 2 files to the skyrim folder or that comes later? Im confused on that part as i though enb is a mod and not something you just extract to the skyrim folder and it does magic :D

[Nebulous112]

No need to "run" the .exe file. Just make sure you extracted the files to the right place, and configured enblocal.ini per instructions.

 

Whenever you run Skyrim, ENB will work automatically (assuming you're using the files from the "Wrapper" version).

 

You should see some text in the top left corner when Skyrim starts. If following STEP Core, it should say in red something like this (paraphrasing), "ENB Graphics disabled, only using memory settings".

 

That text is the best way to know whether ENB is working.

[HypestHypeBoo]

I did all as instructed in the core guide so im guessing it works! Thanks Thane!!

[Nebulous112]

The ENB binary has been updated to v0.303.

 

 

[spoiler=Default v0.303 enblocal.ini]

[PROXY]

EnableProxyLibrary=false

InitProxyFunctions=true

ProxyLibrary=other_d3d9.dll

 

[GLOBAL]

UsePatchSpeedhackWithoutGraphics=false

UseDefferedRendering=true

IgnoreCreationKit=true

 

[PERFORMANCE]

SpeedHack=true

EnableOcclusionCulling=true

 

[MEMORY]

ExpandSystemMemoryX64=false

ReduceSystemMemoryUsage=true

DisableDriverMemoryManager=false

DisablePreloadToVRAM=false

EnableUnsafeMemoryHacks=false

ReservedMemorySizeMb=64

VideoMemorySizeMb=2000

EnableCompression=false

AutodetectVideoMemorySize=false

 

[THREADS]

DataSyncMode=1

PriorityMode=0

 

[MULTIHEAD]

ForceVideoAdapterIndex=false

VideoAdapterIndex=0

 

[WINDOW]

ForceBorderless=false

ForceBorderlessFullscreen=false

 

[ENGINE]

ForceAnisotropicFiltering=true

MaxAnisotropy=16

ForceLodBias=false

LodBias=0.0

AddDisplaySuperSamplingResolutions=false

EnableVSync=false

VSyncSkipNumFrames=0

 

[LIMITER]

WaitBusyRenderer=false

EnableFPSLimit=false

FPSLimit=10.0

 

[iNPUT]

//shift

KeyCombination=16

//f12

KeyUseEffect=123

//home

KeyFPSLimit=36

//num /       106

KeyShowFPS=106

//print screen

KeyScreenshot=44

//enter

KeyEditor=13

//f4

KeyFreeVRAM=115

//B

KeyBruteForce=66

 

[ADAPTIVEQUALITY]

Enable=false

Quality=1

DesiredFPS=20.0

 

[ANTIALIASING]

EnableEdgeAA=false

EnableTemporalAA=false

EnableSubPixelAA=false

 

[FIX]

FixGameBugs=true

FixParallaxBugs=true

FixParallaxTerrain=false

FixAliasedTextures=true

IgnoreInventory=true

FixTintGamma=true

RemoveBlur=false

FixSubSurfaceScattering=true

FixSkyReflection=true

FixCursorVisibility=true

FixLag=false

 

[LONGEXPOSURE]

EnableLongExposureMode=false

Time=1.0

BlendMax=0.0

 

 

As Rebel47 pointed out in the ENBoost 6.0 Anticrash thread, the .ini lines from the Anticrash file are now included in the new version of the ENB binary itself. That is not the only change...EnableCompression is now defaulted to false.

EnableCompression=false

[THREADS]
DataSyncMode=1
PriorityMode=0

Regarding the new .ini lines...this is what Boris says on the ENB download page:

 

Added new ENBoost features which improve stability at cost of performance, check parameters under [THREADS] category of enblocal.ini. Bigger values for DataSync and Priority modes means lower frame rate, more stuttering and higher incompatibility with other software, some previously working screen capturing tools may crash or be extremely slow with new setting other than 0. Developed and tested for mods pack which have 40% crash rate on loading, when DataSyncMode=1 no crashes occurs

 

 

And this is what he says on the Crash Fix ENBoost Nexus page description (formatting of middle paragraph by me): 

 

ENBoost is a patch for memory limitations of the game, some optimizations and other fixes.
In new version 6.0 I've added [THREADS] category to enblocal.ini configuration file to apply
fixes to multithreading code, which is one of the most buggy thing of game engine. Because
I don't have sources, the cost of these changes is performance and stuttering, which in their
turn depends from CPU, OS and some other software installed (overlays, screen captures, etc).

Because of negative performance impact when two new variables enabled, it's better to activate
them only when you have non loading game (saved in too "heavy" place or too many mods) or
actions in the game leads to crashes (like i have with some dialogs of the new followers). To
disable (but keep memory setting only), set DatasyncMode=0 and PriorityMode=0 in enblocal.ini.

Tested and developed on 22 Gb mods pack with various environment and body texture/models
modifications, including SKSE plugins. Loading saved games created with it have 40% chance
to get random crash on load in the tested place and 100% chance of crash in another two. With
new ENBoost these places loaded fine 20 times in a row and I used preset, which is published
here. But because of different rigs and "density" of mods and their CPU usage, implemented
several modes with different level of stability, some of them probably not much playable, but
may help to load game and resave it again in less stressful place for the engine and scripts.

 

This tells me that most users should have these fields set to "0", unless trying to load a save that crashes, or trying to get past some really crash-prone area. For STEP, this should not be an issue. :-)

 

 

Boris goes on to say on the ENBoost Crash fix page:

 

DataSyncMode have the range of 0..2 at this moment, this is not boolean variable. Value=0 disables patch
PriorityMode have the range of 0..4 at this moment, this is not boolean variable. Value=0 disables patch

At this moment DataSyncMode=2 with PriorityMode=3 where tested

by users as the most performance efficient and stable setting.

Changes made to skyrim.ini and skyrimprefs.ini regarding more threads affecting stability and
performance in bad way, so it's recommended to restore default values.

 

So, it seems like the values for these fields are whole numbers, from 0-2 and 0-4 respectively. There are some recommended numbers for the new fields, and Boris also recommends not to change any values related to threads in Skyrim.ini or SkyrimPrefs.ini. For STEP, I think it's better to recommend just turning these new fields off (just as everyone else said in the other thread)...STEP users shouldn't be crashing all over the place, anyway. ;-)

 

[THREADS]
DataSyncMode=0
PriorityMode=0

Also, should STEP recommend that compression is turned back on? Or is this better left off by default for STEP (if we assume most have >2GB VRAM)? Again, the previous recommendation with v0.279 was to keep this at the default value (which was "true"), but the default has now changed to "false".

 

EnableCompression=true

[aristotle]

I've been playing Skyrim for a while now, but recently have new desktop crash problems.  I installed ENBoost v0.303.  There were no (or very minimal) crashes until I got to about Level 30, now they seem to happen every 5 minutes.  Most notably, outdoors (not in towns or buildings).  Also, traveling by carriage between towns, desktop crash shortly after arriving.  My settings are:

 

[GLOBAL]
UsePatchSpeedhackWithoutGraphics=true
UseDefferedRendering=false
IgnoreCreationKit=true

 

[MEMORY]

ExpandSystemMemoryX64=false
ReduceSystemMemoryUsage=true
DisableDriverMemoryManager=false
DisablePreloadToVRAM=false
EnableUnsafeMemoryHacks=false
ReservedMemorySizeMb=256
VideoMemorySizeMb=2134
EnableCompression=true
AutodetectVideoMemorySize=false

 

[WINDOW]
ForceBorderless=true
ForceBorderlessFullscreen=true

[ENGINE]
EnableVSync=true
VSyncSkipNumFrames=0

 

I have an OLD Windows XP computer:  Windows XP Professional 32 bit SP3, Intel Pentium D, 4 GB RAM, 2 GB Radeon HD 6450 graphics card.

 

I have many mods, not going to list them all unless asked to, there are maybe 20-30.  I have Dragonborn, Dawnguard, HearthFires.

 

I don't understand why Skyrim was playing fine until about Level 30, now I get repeated desktop crashes.  Please help!

Thanks
 

[TechAngel85]

Do you have SKSE installed with the Memory section filled out? Have you checked to see how much memory the game is using (Skyrim Performance Monitor)?

[aristotle]

Thanks for the quick response :)

 

Yes, I have this in my skse.ini file:

 

[General]
EnableDiagnostics=1
ClearInvalidRegistrations=1

[Display]
iTintTextureResolution=2048

[Memory]
DefaultHeapInitialAllocMB=768
ScrapHeapSizeMB=256
 

 

.... which skse.ini file is located here:  C:\Program Files\Steam\steamapps\common\Skyrim\Data\SKSE

 

 

As for Skyrim Performance Monitor, no, I haven't yet used that.  I had a quick look at the STEP wiki guide for Skyrim Performance Monitor, and it said to make sure I had Microsoft.NET Framework 4 installed.  I checked, and it turns out I only had 3.5 installed.  So I downloaded version 4.

 

Will report back once I've played the game some more.  Thanks again.