GUIDE ENB Guide

[TechAngel85]

Hey Tech - alt3rn1ty was actually referring to a recent post by me on the thread about Sheson's Memory Blocks Log and despite what I've said before regarding ExpandSystemMemoryX64, I now believe that the STEP ENB Guide's recommendation should be to set it to false.

 

The reason for this is that STEP also recommends increasing the "Block 1" heap allocation in the SKSE.ini, and with help from hishtup, I have confirmed there is direct relationship between the ExpandSystemMemoryX64 setting and using Sheson's Memory Patch fix (with either implementation - SSME or SKSE) to increase the "Block 1" allocation.

 

If ExpandSystemMemoryX64 is set to true, after the "Block 1" allocation is set above a certain number, Skyrim will crash just before the main menu. For me, this happens when "Block 1" is over 512MB, though I've read user reports of it happening closer to or just past 768MB.

 

Before hishtup told me about his findings, the only way that I knew of to allow Skyrim to run after the "Block 1" allocation causes it to crash is to increase the "Block 2" allocation to 512MB. However, using Sheson's Memory Blocks Log and other tools, I and other people have observed Skyrim still never actually uses over 256MB for "Block 2". So that additional 256MB allocated to Block 2 is essentially wasted.

 

Then, after I posted an explanation of how the Memory Blocks Log tool works with a bit of history regarding Sheson's Memory Patch Fix, hishtup told me that if ExpandSystemMemoryX64 is set to false then Skyrim won't crash based on the "Block 1" allocation. From this, I realized that increasing the "Block 2" allocation should not be necessary.

 

So, I did some tests and can confirm that this is correct. With ExpandSystemMemoryX64, set to false, I can set my Block 1 allocation even over 1GB, and Skyrim doesn't crash when started, and I do not need to increase the "Block 2" allocation.

 

In retrospect, this make complete sense, because based on the source code of the ExpandSystemMemoryX64 feature that Boris posted on the ENB forums, it uses a system memory allocation function call (MEM_TOP_DOWN) to change the allocation of memory from the "bottom" of the memory space of a program to the "top" of its memory space. The MEM_TOP_DOWN call is intended to be used for testing when converting a 32-bit application to 64-bit.

 

I did quite a bit of research about MEM_TOP_DOWN, and although my findings were inconclusive, I never found any evidence to fully support the idea that it would allow memory to be used more efficiently. For an enlightening and interesting article on MEM_TOP_DOWN, you can check out this blog post by Bruce Dawnson, a programmer at Google (who used to work for Valve). Scroll down to the bottom of the page, and you will see my questions to him that I asked back in March last year.

 

So I highly recommend changing the ENB Guide to suggest setting ExpandSystemMemoryX64=false in enblocal.ini as the default, and adding an explanation about its effects on the Sheson Memory Patch fix.

 

For the explanation, my suggested edits:

 

(9 Jan 2014, 3:52PM GMT -7: I edited my explanation of what hishtup told me, for clarity, and added some interesting, relevant and factual links.)

I lean to you and your expertise in this matter and will do as you recommend. Your knowledge on the subject is far greater than my own in this regard.

 

keith,

 

I am on 64 bit system. I use both ENB and Sheson's fix. My "Block 1" never goes over 512MB.  

My current setting is ExpandSystemMemoryX64=true

 

- What is the downside of setting ExpandSystemMemoryX64=true?

- What is the benefit of changing it to ExpandSystemMemoryX64=false?

 

Thanks for a great information

I too am interested in a precise answer to those questions.

[TechAngel85]

I've updated the Guide with your recommendation.

[TechAngel85]

I've completed my review of the changes on the Guide and am also done with my updates. The Guide's conversion to TOC should be complete now.

[z929669]

I am doing an extensive readability overhaul of this guide. Why? Because I am currently following STEP 2.2.9 in laborious detail, using all guide articulation to mods and ancillary guides/info and noticing that some aspects of this articulation and content are quite difficult to follow.

 

What I am changing:

• altering document flow properties and general organization so that it is easier to read
• organizing headings so that information is easier to find
• enhancing articulation with other site guides and info
• increasing consistency with how we handle presentation in other guides

What I am NOT changing:

• content (other than fixing typos and syntax)
• links to external info

[TechAngel85]

Yeah, seen you were doing some editing because I was troubleshooting with a user and content was disappearing and changing on him. lol

 

I've updated the ENBoost mod page for the VideoMemorySizeMb section to better align with the Guide. I'll also be update the ReservedMemorySizeMb section as well since setting it to 512 is not the best for every user. These new values are more sound than what we had previously.

[z929669]

Yeah, sorry about that ...

 

Thanks for the updates.

 

Once I am done (may take awhile), maintenance of this guide should be greatly simplified. Currently trying to compact info that is reproduced in several places. Taking a break now, so content should be fairly stable for a couple of hours ;)

[z929669]

My first pass for the day (I think) is complete.

• Removed ENBlocal "Quickstart" section content (we already have it on the ENBoost mod page, so that is linked instead)
• Removed "Enblocal.ini" section content and ported to INI Guides/Settings pages as we do for ENBseries INI (replaced content with a link to subguide)

More later tonight or tomorrow ...

[TechAngel85]

As for the issue with the ExpandSystemMemoryX64, it is detailed on the previous page. Although, I too had no issues, that doesn't mean others don't with lesser cards. Keithinhanoi is the authority on the Enblocal.ini file as far as I'm concerned and I hold his findings up there with Boris himself.

[z929669]

Duly noted. I will update accordingly.

 

Thanks!

[TechAngel85]

You removed the part instructing on how to install the Injector version of ENBoost without adding it to the ENBoost mod page.

 

EDIT:

Added it to the mod page.

[z929669]

I am finished with my edits to the guide:

• Removed redundant information that already exists elsewhere on the wiki:
  • Offloaded ENBoost quickstart to the mod page and replaced with brief description and link to mod page
  • Offloaded all enblocal.ini section/parameter descriptions into their own subguide (same as ENBseries INI subguide)
  • Removed most of the INI-section/parameter descriptions due to redundancy with ENBseries INI subguide
• Reorganized some of the chapter hierarcies and headings
• Reformatted applicable path strings to use HTML tags
• Resized a few images and removed others that seemed totally redundant.

Regarding redundant info duplicated throughout the wiki:

It is best to either link to a single source from ancillary doc or create a template to hold information that we think should be reproduced in more than a single location. The problem is that one location will be updated, but the other will not, which leads to conflicting info (=bad). Better to manage in a single place, as it reduces potential for error and significantly reduces the maintenance burden. Some existing elements are already reproduced in various locations (e.g., Skyrim INI settings, GPU driver settings, others).

 

EDIT: There may be an extension to handle centralizing text snippets from normal pages to be transcluded into other pages for reuse:

Labeled Section Transclusion

[keithinhanoi]

keith,

 

I am on 64 bit system. I use both ENB and Sheson's fix. My "Block 1" never goes over 512MB.  

My current setting is ExpandSystemMemoryX64=true

 

- What is the downside of setting ExpandSystemMemoryX64=true?

- What is the benefit of changing it to ExpandSystemMemoryX64=false?

 

Thanks for a great information

Somehow I missed this - so many apologies for the late response!

 

If you have no need to raise your block 1 heap allocation over 512MB, then the only potential downside to ExpandSystemMemoryX64=true is increased instability in the form of random CTDs. But that is just based on user reports I've read. Personally, knowing everything I do about how ExpandSystemMemoryX64 actually works, I can't find any compelling reason to turn it on unless you have evidence that it reduces the change of CTDs while playing.

 

While for me, the setting does not seem to have any effect on stuttering, FPS, or perceived smoothness of rendering, others have reported that turning it off helps reduce stuttering - so that would be a benefit of changing it to ExpandSystemMemoryX64=false.

 

Also, keep in mind that while at v0.251, Boris removed ExpandSystemMemoryX64=false after some number of users reported problems with it being turned on, and then later brought the option back due to users asking for it, but changed the default in the included enblocal.ini with the ENB download to false. He has stated, however, that it is "good for certain things", and helps him personally with stability on his own system.

 

So - I say try doing some tests with it on and off to compare stability, stuttering, FPS, and smoothness of rendering. 

 

Despite this, I still strongly believe the default setting should be false when a user first installs ENB, and then they can experiment with turning it on to check if there are any improvements. If not, then just leave it off.

[darkside]

Thanks for the detail answer, keith. Will test it out.

[junglejudas]

VideoMemorySizeMb

... Users with 64-bit systems and at least 8GBs of system RAM, can use the formula: (VRAM + System RAM) - 2048 ...

VideoMemorySizeMb=(512,1024,...6144)

to clarify, since i'm still rather ignorant of how memory works:  "system RAM" is referring to the physical memory on board, and virtual is not to be included in this context?  (i run 64-bit win7, have 8GB virtual but only 4GB physical, and my graphics card has 2G physical/2G virtual, so:)

 

(1) "playing it safe", i assume i should keep this setting at 2048?

 

  alternatively, would virtual and physical be added together?  it seemed too good to imagine that i could set this at 14336...  speaking of which (regardless of my own limitations):

 

(2) is the implied "set limit" of 6144 arbitrary, or does ENB (or something else) not actually support higher totals?

Edited February 4, 2015 by junglejudas

[Aiyen]

It is only physical that matters, since it is the "fast" type of memory... virtual memory is just a slow type of cache. You would not want to read several GB´s off a disk since even on an SSD it would take too long compared to the milliseconds it takes in physical memory. 

 

If you only have 4Gb of physical you should not set it higher then 2048... since then windows will most likely just pop up with an "out of memory" error and shutdown. In general using ENBoost only really works if you have more then 4Gb of RAM. 

 

for the 2nd one. You can set this value to almost any height, however it will not really make sense to set it higher then 10Gb.. since making skyrim reach that amount of texture load will most likely cause other bottlenecks to appear due to the insane amount of load required.