Correct Enblocal Settings

[prizner]

So I was installing SkyRealism using the enb guide and I noticed the site https://www.iparadigm.org/pages/pnenb/ENBoost.html used for getting parameters for the memory section of enblocal no longer works. After some digging I found there were some formulas to come up with the needed information but as I am still unsure if I fully understand them I was wondering if anyone here could help? I have gtx 680 4GB and 12GB of ram with a i7 980x. Thanks!

[MadWizard25]

-snip-

 

Phew, thanks for the info keithinhanoi. Didnt expect something so complete or in depth 

 

I will try with X64 set to true again, while altering other values. Mind you I run the enblocal.ini file provided by RealVision ENB, so I have yet to test the default 0.252 version.

 

I did get crashes with 1.7 skse and X64 set to true (crash at load save game), but that was with all other settings at default. However, I did find a post on the ENB forums where there was a complaint about the same problem. Boris posted that it was an incompatibility. Unfortunately, he did not clarify if it was a universal issue, or something due to specific system/ mod setups, as you have posited. If you want I can try to find the source, since Its possible i mis-remembered. Ill get into some extensive testing later.

 

As to the 4GB VRAM usage. It puzzles me slightly. I DDSopted everything to 2k, except for exterior normals which were optimized to 1k. I do run an extremely heavy mod setup though. Im talking 600 mod installs, with 350 plugins (huge merge amount). I suspect it has to do with so many additional exterior NPCs and spawns, as well as ugrids being set at 7. All that plus the performance ENB from Real Vision.

 

So generally;

X64 set to true

Reserved set to 256/ 512

MemorySize set to 10240 (4GB VRAM + 8GB RAM)

Compression set to true or false.

 

I should also mention im using Win 8.1 x64, with beta Update 1 installed. I know Win 8.1 and the latest update 1 handle memory a whole lot differently than win 7. By default my win 8 uses more RAM than win 7. Perhaps this also makes a difference.

Edited April 10, 2014 by MadWizard25

[Kuldebar]

Interesting. A few questions;

 

1. Have you found any significant differences with EnableCompression set to false?

 

2. Im running skse 1.7 alpha. With ExpandSystemMemoryX64 set to true, skyrim crashes for me. Boris did say that this was a compat issue, and hes not fixing it. Do you run skse 1.7, and if so, how are you avoiding the crash?

 

3. You mention upping ReservedMemorySizeMb higher if you have limited VRAM. By limited VRAM do you mean purely in regards to your computer, or in regards to Skyrim? I have 4GB VRAM, which I would not call limited in regards to computers. However, in Skyrim exteriors i frequently hit my VRAM limit, so it could be limited in regards to Skyrim.

• I haven't experimented with compression off in quite a while, but when I did (and I have) ...it wasn't positive for me...I had more stutter issues versus having none with it enabled. 
• I had issues with ExpandedSystemMemoryX64 in the past, but I had more issues in the long run without that setting enabled. Also, the problems with CTD's faded away as I started upping ReservedMemorySizeMb and using "reality based" VideoMemorySizeMb numbers.
• Limited VRAM, as Keith said, means my 1GB physical VRAM GPU.

[MadWizard25]

 

• I haven't experimented with compression off in quite a while, but when I did (and I have) ...it wasn't positive for me...I had more stutter issues versus having none with it enabled. 
• I had issues with ExpandedSystemMemoryX64 in the past, but I had more issues in the long run without that setting enabled. Also, the problems with CTD's faded away as I started upping ReservedMemorySizeMb and using "reality based" VideoMemorySizeMb numbers.
• Limited VRAM, as Keith said, means my 1GB physical VRAM GPU.
•  

 

 

Thanks!

 

ExpandSystemMemoryX64=true definitely crashes my skyrim, much like a missing master CTD. Changing other values makes no difference. Quick search of ENB forums shows I'm not alone with this type of CTD.

 

I guess its my mod setup somehow 

Edited April 10, 2014 by MadWizard25

[prizner]

Just wanted to say thanks again to everyone in this topic! After yesterday I though I had this pretty well figured out for what I was trying accomplish. However now I know I am going to be testing and tweaking for the next few weeks just trying to see what works the best.

Edited April 11, 2014 by prizner

[z929669]

@keithinhanoi

I see that you are giving ENB settings some focused attention and that you are writing up a guide of sorts on this. Are you using the wiki for this? If not, I encourage you to do so, and I will use that as a resource for our guide.

As little as one month ago, I was pretty versed in my understanding of ENBoost and the way it manages memory, but I lose all info that I do not regularly recall on almost a daily basis ... been taking a break from Skyrim stuff lately.

As I recall, ENBoost parses TESV.exe allocated memory onto the enbhost.exe process, effectively obviating the 32-bit process cap and preventing the crash. At the same time, ENBoost ensures that this is done only after utilizing all D3D9-related VRAM capacity ... ultimately, this post (the Jafin16 quote) does not jive with me and seems to convey some misinformation (although it may effectively be correct), but I cannot address with convenience at this time. Perhaps you can? IIRC, ENBoost does not stop D3D9 mirroring of VRAM to sys RAM, nor does it 'reduce' utilized sys RAM ... it just ensures that all game memory has a valid place to 'live' in the most efficient manner for use with video rendering ... ?

 

 

EDIT: Oh, and VSyncSkipNumFrames=0 (use all back-buffer frames) was mentioned above for some reason and was not addressed ... leave this at zero if using EnableVSync=true (as recommended by STEP). Changing to one or greater will most likely cause a strobe effect. AFAIK, this setting theoretically allows certain configs to better sync the video memory back buffers (vsync) based upon frame rates "wanting to be" consistently greater than monitor refresh rates (i.e., the GPU efficiency), which is pretty rare for fully modded setups on even very powerful systems. I am not sure if it works for anyone, but I assume that this might be helpful for VERY powerful video cards running with vsync (and 60 Hz monitor refresh rates).

[EssArrBee]

We should do a very limited ENB that only covers a few things. Shadows, parallax, DoF... I bet we could just strip out all the stuff from the .fx files that we don't need and get it to only cost 6-8 FPS.

[thommaal]

A guide would be nice. I have always stuck to the card VRAM - 128Mb rule for VideoMemorySizeMb; but lately, I have tried out variations of  "VRAM+RAM-2048", which in my case leads to 9126. However, the smoothest result shows up with 8192. Even some annoying problems with shadows are nowhere to be seen. It still seems to be trial and error.

Edited April 12, 2014 by thommaal

[Jafin16]

 ... ultimately, this post (the Jafin16 quote) does not jive with me and seems to convey some misinformation (although it may effectively be correct), but I cannot address with convenience at this time.

Hi there,

 

I usually don't lurk around here too much (maybe I should more, lots of good stuff), but I just happened to run across this thread and I just want to clarify that the information I've given and was quoted here is simpky a lot of information Boris has shared about ENBoost since its inception that I've distilled into the short post there. There is a lot more involved of course, but for the general user, that's the info you need. I'm curious what might seem to convey some misinformation. If you look at the thread Boris commented 2 comments after me, addressed the person who inspired the original post and said this in regards to it:

 

 

SirCrest

Jafin16 explained everything

Original Post

 

Regarding the formula for setting VideoMemorySizeMb, the VRAM+RAM-2048 is for a 64-bit OS running at least 8GB of VRAM. What some of you have seen around recently about setting the value to VRAM minus a little bit (like 128MB) is intended for a 32-bit OS or 64-bit OS with less than 8GB of RAM.

 

Regarding ExpandSystemMemoryX64 I can't say in regards to SKSE 1.7. As of yet, it's still alpha, it is not required for any mods I have or am aware of, and SSME works fine for Sheson's Memory Patch with SKSE 1.6.16 so I don't see a reason to switch to an alpha build at this time. I believe Boris did a fix in one of the 0.250 (or just before 0.250, can't remember) builds to help compatibility with SKSE but I don't know exactly what he did there or how effective it's been. Those complaining (one person mostly) simply left and haven't posted at enbdev since.

 

@keithinhanoi

The recent increase to allowed memory at 128 GB applies to enbhost.exe, not VideoMemorySizeMb. I do find it interesting that auto-detect showed 15-17GB of VRAM, however, according to Boris most recent information, the limit for that setting is still 10240. You can set it higher, and it will show higher, but ENB will not use more than 10GB, regardless of what that shows.

 

However, for all of this, there are a lot of variables to consider, such as your motherboard, RAM speed, even Graphics Card bus speed. These are all the values to START at, and then tweak based on what works on YOUR system, hence the reason the implementing of the enblocal.ini file - it's specific to YOUR system and is meant to stay there.  For reference I'll post my relevant system specs here and my ENB memory settings.

 

Happy modding/tweaking/gaming!

 

-Jafin16

 

PC Specs:

AMD FX-8120 @3.3GHz,4.4GHz boost

12GB DDR3 1600MHz

AMD Radeon R9 290 w/ custom OC

Gigabyte GA-970A-UD3 Mobo

 

ENBoost Memory settings:

[MEMORY]

ExpandSystemMemoryX64=true

ReduceSystemMemoryUsage=true

DisableDriverMemoryManager=false

DisablePreloadToVRAM=false

EnableUnsafeMemoryHacks=false

ReservedMemorySizeMb=512

VideoMemorySizeMb=6144 //8192, 10240 work just as well. Set to 6144 to free sys ram for other needs.

EnableCompression=false

AutodetectVideoMemorySize=false

Edited April 13, 2014 by Jafin16

[thommaal]

Thanks for the input, Jafin16. VideoMemorySizeMb depends so much on the processes running in the background that the optimal amount will always be specific to one's own system. When I switched antivirus programs, I could suddenly use the 64bit-formula to some extend. After an update to my databank, 8192MB have become the optimal setting.

 

Since you are present, I'd like to ask you 2 questions:

 

1. "FixCursorVisibility=true". Does it do the same as Double Cursor Fix?

 

2. Is "DisableDriverMemoryManager=false" also the correct setting for ATI cards?

[DoubleYou]

Most of the time I disable internet and antivirus before starting Skyrim.

[thommaal]

Yeah, I've done this in the past with other games whenever my system reached its limits. Not there yet. Not quite.

[MadWizard25]

Im using enb 0.252 and skse 1.7 alpha. ExpandSystemMemoryX64=true really does CTD my game like a missing master. I have 8GB RAM and 4GB VRAM and 64 bit Win 8.1. So i should qualify for its use. The problem has persisted since 0.250 as well. 

 

1.6 skse with SSME solves the issue and allows me to run with it set to true. However, I have mods that require 1.7 alpha skse. Ill live with setting it to false. Its not necessary anyways. And not big enough of an issue to post on ENB forums, especially since it s probably a compat issue with other software like anti virus or something.

[Jafin16]

 

1. "FixCursorVisibility=true". Does it do the same as Double Cursor Fix?

 

2. Is "DisableDriverMemoryManager=false" also the correct setting for ATI cards?

1. If I remember correctly, yes, except it's implemented by ENB which is nice for keeping everything in one place.

 

2. That totally depends on the ATI/AMD card and the driver version for it. Basically, if you have a buggy driver that doesn't handle memory management properly for ENB set this to true. Then dx9 and a variety of other factors will manage memory. For my R9 290 with latest 14.3 beta drivers, I have no problems. However, when I used a HD 7870 around 13.10 and early 13.11 beta driver builds I had to set it to true. Others with similar cards have had different experiences too. The thing is, Skyrim is SO BAD at handling memory that there's no sure-fire way to go. I haven't heard of anyone having problems with the 13.12 WHQL drivers from AMD at all or and of the 14.x beta drivers, nor have I had any issues since then either. Test it with both for stability and responsiveness and use what works best. Anything that still holds the actual ATI branding (HD 5xxx series and lower) will probably need it set to true.

 

The thing with ENBoost features is there is no certain 100%-this-is-how-to-do-things-to-make-it-work because of the nature of varying systems. Everything we have are guidelines (albeit good ones) and so each person needs to make things work best for their system. However, by sticking to the guidelines and then making variations within those guidelines is the best way to go.

 

Hope that helps :)

[z929669]

@Jafin16
I am not saying you don't know what you are talking about ... I'm just a stickler for getting the facts straight, even in a simplified explanation. The most important thing is that nothing is stated that is not factually accurate. You did provide a disclamer, but people still hone in on little details and regurgitate them elsewhere (i.e., inconvenient misinformation). You mentioned that:

What ENBoost does, in short (and I may be wrong on some of the exact specifics, but this is the gist of it), is it frees up the system memory, by not mirroring everything and offloading some of that to VRAM, and some a large chunk of it gets offloaded to the enbhost.exe application.

My issues are with (experts correct me if I am wrong):

"frees up system memory" - My understanding is that it does not free up any memory at all, but rather it reallocates memory.

"not mirroring" - My understanding is that mirroring VRAM is inherent to D3D9, and that it cannot be stopped (or at least that ENBoost does not stop this).

 

As I said above, my generalized understanding is that ENBoost reallocates memory from the TESV process by allocating as much GPU memory as possible into VRAM (I would think the most recently accessed info). This maximizes the use of the most efficient memory for graphics (VRAM). Once VRAM is maxed out, it is my understanding that it uses the enbhost process to hold the excess (I would think the oldest GPU memory) ... and IIRC from inspecting my own processes while running ENBoost, I think that multiple enbhost processes can exist to hold excess and prevent the 32-bit related crashes relating to the 4 GB limit of each of these processes.

 

Based on my own interpretations, Boris does not relish posting (particularly in English), and he will often gloss over detail (or avoid it altogether) in order to avoid posting in detail. ... this is probably why he deferred to your post with his own post that you quoted above. Your simplified explanation may have been 'close enough' (my guess anyway).

 

This is one reason why documentation on ENB is severely lacking (IMO) ... another important reason is that ENB is updated so often that doc may quickly become irrelevant or downright incorrect. This is all preferable to Boris spending a lot of time on doc that would otherwise be spent on devel (which is the case now I assume). Nevertheless, I wish he had a partner. A countryman of his own that he could explain detail to in his native tongue who could then document everything and translate it all into English. Too much to ask, I am sure, so no complaints from me!

 

The best we can do then is to try to understand as best we can and carefully state things in posts and other communiqués so that they are reproduced by others to provide a consistent message that we hope is correct

 

I adopt this position mostly due to my own selfishness, because I forget what info I do not continuously use over and over again :P

 

EDIT: A good way to look at the ENBoost behavior is to use uGrids 17+ (with Sheson's patch and Stable uGrids mod).

[Kuldebar]

I can "free up" more usable space in a container by modifying how the items within said container are distributed...so, semantically, I find the concept of "freeing up memory" to be absolutely correct in this case. :)

 

In relaying concepts to people, I find it best to give people a frame of reference to rely upon so they can build their own understanding, all the exceptions to the rules and other such complexities can be addressed later after they get the basic idea. At least, that's how it works for me.