Jump to content

Question

Posted

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!

Recommended Posts

  • 0
Posted (edited)

Based on my specs above do you have any thoughts on what my video memory size should be set to? I am a little apprehensive to set mine that high considering I have only 12gb of ram and then 4gb on my card. Where you seem to have a little more headroom in ram.

Edited by prizner
  • 0
Posted (edited)

Given your abundance of RAM, you can even get a bit higher at

 

ReservedMemorySizeMb=

 

768-1024 are values that were recommended by Boris on more than one occasion.

 

10240 MB is indeed the max. value for "VideoMemorySizeMb". The optimal formula is

 

your Video Memory Size - 128 MB.

 

But if you add the max. value, it won't make a difference. But cards with just 1024 MB RAM should use the formula and add

 

1024 - 128 = 896

 

as the best value. I also comply to this with my 3GB ATI.

Edited by thommaal
  • 0
Posted (edited)

Actually, the information I gave, needs a huge disclaimer. I cite jafin16 from an ENB forum thread:

 

 

The memory management features of ENBoost (included in ENBSeries) affect both RAM and VRAM. Essentially, a DirectX 9 application (like Skyrim) mirrors the textures loaded into vram, in the RAM as well. The whole issue is that when Skyrim hits 3.1Gb of RAM (NOT vram) the game crashes, because it's a 32-bit application and can't handle more memory. 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. So the 128gb future proofing that Boris did is for system RAM, NOT vram. Vram isn't really a factor. I mean, the more you have, the better, but I have never used my 4Gb of VRAM and I have a MASSIVE load order with a lot of texture/mesh packs installed and a fairly heavy ENB setup. However, if I add up system ram used by Skyrim and ENBhost.exe I regularly hit right about 3.5-4gb.Anyways, hope that explains it.TL;DR It's for system memory, not video memory.Oh, and one last thing. The parameter, VideoMemorySizeMb parameter does indeed tell ENB how much VRAM you have. However, if you set it to a higher amount, the game will then be able to use some of your system memory as VRAM. RAM isn't usually as fast as VRAM but more is always better. The formula you've seen go around is for 64-bit OS's and is VRAM+RAM-2048=VideoMemorySizeMb (maxes out at 10240). I set mine to 8192 (see my system specs below.)

Edited by thommaal
  • 0
Posted

Why not just use the autodetect feature?

 

 

At first i was going to but then I read so many conflicting comment on some people saying use your base vram as parameters (which auto detect seems to use) other saying use more than vram aka ram+vram-2048. So I though i would just ask some people with more experience. Thank you all for your help I think I have it figured out now

  • 0
Posted

Actually, the information I gave, needs a huge disclaimer. I cite jafin16 from an ENB forum thread:

 

 

 

The memory management features of ENBoost (included in ENBSeries) affect both RAM and VRAM. Essentially, a DirectX 9 application (like Skyrim) mirrors the textures loaded into vram, in the RAM as well. The whole issue is that when Skyrim hits 3.1Gb of RAM (NOT vram) the game crashes, because it's a 32-bit application and can't handle more memory. 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. So the 128gb future proofing that Boris did is for system RAM, NOT vram. Vram isn't really a factor. I mean, the more you have, the better, but I have never used my 4Gb of VRAM and I have a MASSIVE load order with a lot of texture/mesh packs installed and a fairly heavy ENB setup. However, if I add up system ram used by Skyrim and ENBhost.exe I regularly hit right about 3.5-4gb.
 
Anyways, hope that explains it.
 
TL;DR It's for system memory, not video memory.
 
Oh, and one last thing. The parameter, VideoMemorySizeMb parameter does indeed tell ENB how much VRAM you have. However, if you set it to a higher amount, the game will then be able to use some of your system memory as VRAM. RAM isn't usually as fast as VRAM but more is always better. The formula you've seen go around is for 64-bit OS's and is VRAM+RAM-2048=VideoMemorySizeMb (maxes out at 10240). I set mine to 8192 (see my system specs below.)

I gave this a quick test and I think it really improved my performance! I have 2 GB graphic card and 8 GB of ram. I set VideoMemorySizeMb to 2048 (as per my VRAM) and I must say that sometimes I get big stutter when turning around (a clear indication of hitting VRAM limitations), especially when there are a lot of NPC in the picture (I use 1K for exterior textures, but 2K for NPCs and most of the equipment). 

 

I have changed VideoMemorySizeMb to 8192 (as per the formula above) and loaded a recent save, where a large battle occurs (Extended Encounters mod), something between 15-20 NPCs (my char + 2 followers, some bandits, a Redguard party, a giant, a farmer with a cow, some mercenaries  etc. - so A LOT of different textures loaded) and the battle went really smooth, only some minor stutters when turning around.

 

As I said, this was only a quick test in a spot I knew is bad, as I've had some problems with it yesterday when I played - first time I encountered it my game froze for about 30 seconds during getting off my horse, then another 15 sec freeze when I tried to turn back and run to fight. Now all played very smooth, no issues. 

 

I will do some more testing soon to confirm, but initial thoughts are that this formula is actually working. I just hope it's not a placebo! 

  • 0
Posted

The formulae is in theory sound... the main issue it is that is assumes that you also have a super optimal motherboard, and otherwise decent system that can handle the bandwidth you request it to do. 

 

In general if you get any excessive stuttering, slowdowns etc. then it all comes down to just trying to alter those two values.... and your driver version ofc

 

 

I have used 8192 with 2Gb VRAM and 16Gb RAM since ENBoost came out and it has been the best option ever since... I could go to 10Gb but never saw any indication of the game asking that much with my memory requirements... it usually caps out around 8Gb. 

 

ofc. you will most likely ALWAYS get some stuttering when scrolling around really fast, and when loading new cells, but this is to be expected... people tend to forget that skyrim is a giant openworld game... not a closed in single player level with highly efficient LOD generation. 

  • 0
Posted (edited)

The formulae is in theory sound... the main issue it is that is assumes that you also have a super optimal motherboard, and otherwise decent system that can handle the bandwidth you request it to do.

It always comes down to the specific system at work. The first formula I mentioned works well even for low-end systems, the second one is better suited for higher end and well maintained systems. The hardware is definitely an issue here, as is the OS; 64bit users seem to fare better (not surprisingly) - but, in the end, it boils down to: Just give it a try.

Edited by thommaal
  • 0
Posted

Hm.. from what I've read leaving a little vram for other applications can be beneficial, e.g. going for 2000 in case of 2048 mb vram. Maybe this explains Rootsrat's crashes but appearently the outcome can vary from setup to setup.

I'm wondering why there isn't an explicit feature to preload textures to ram. From what I've read the method of setting VideoMemorySizeMb above vram seems unofficial but works for some people (Boris once complained about people setting VideoMemorySizeMb to high amounts). The downside for people having access vram could be that vram is crammed with textures you don't need while the textures you do need are in ram when turning around. This is speculation though as I do not understand much of the inner workings of ENBoost.

Ayien what texture resolution do you use? Maybe ENBoost just preloads as many textures as it can while leaving some working space.

  • 0
Posted

Hm.. from what I've read leaving a little vram for other applications can be beneficial, e.g. going for 2000 in case of 2048 mb vram. Maybe this explains Rootsrat's crashes but appearently the outcome can vary from setup to setup.

I'm wondering why there isn't an explicit feature to preload textures to ram. From what I've read the method of setting VideoMemorySizeMb above vram seems unofficial but works for some people (Boris once complained about people setting VideoMemorySizeMb to high amounts). The downside for people having access vram could be that vram is crammed with textures you don't need while the textures you do need are in ram when turning around. This is speculation though as I do not understand much of the inner workings of ENBoost.

Ayien what texture resolution do you use? Maybe ENBoost just preloads as many textures as it can while leaving some working space.

Just to clarify - I don't get VRAM/RAM related crashes, I don't get other CTD's ofter either tbh. It's clearly not enough VRAM problem, as the game freezes when it tries to load new textures as the camera rotates the view. Once the textures are loaded, it comes back to normal. And again - these freezes happen ONLY where there are a lot of various NPC's in an exterior area - it's pretty much OK in the cities as well, only happens in the open world with load of NPCs

 

I will do some more testing soon and report back. And yeah, I agree there are a lot of factors to whether it works or not, like hardware set up, OS architecture, other software running in the background etc.

  • 0
Posted

I threw out the VRAM formula weeks ago and just started using my actual GPU Memory Amounts. In DXdiag it will tell you on the display tab what your approximate "total" video memory is and that's the best number to use minus a little bit overhead.

 

For example:

 

DXDiag tells me 4095 MB's, so I use 3968 for VideoMemorySizeMb.

 

Weeks ago, with great success, I also have started using much larger ReservedMemorySizeMb settings. Boris has dropped a few bombs of late concerning how that settings interacts and the just of it is if you have limited VRAM, upping that setting to a larger percentage of you physical VRAM might be beneficial. I have 1GB VRAM, so I set mine at 512 or 768 depending on the ENB Preset that I am running. So, ENB is juggling my Skyrim with these settings:

 

[MEMORY]
ExpandSystemMemoryX64=true
ReduceSystemMemoryUsage=true
DisableDriverMemoryManager=false
DisablePreloadToVRAM=false
EnableUnsafeMemoryHacks=false
ReservedMemorySizeMb=768
VideoMemorySizeMb=3968

EnableCompression=true
AutodetectVideoMemorySize=false

 

They are tailored to my system.

  • 0
Posted

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.

  • 0
Posted (edited)

I've got a 1GB AMD like Kuldebar, albeit quite a bit slower.

 

1. Enable Compression helps us on VRAM usage as we're limited on actual physical video RAM memory (which I'm sure is what Kuldebar meant.)

 

It also can slow things down a bit - translating to stutter or lack of "fluid motion" in game in areas where a significant number of textures are getting loaded / unloaded. The compression is applied when moving data from system RAM to VRAM, IIRC, because that where it's assumed your working with constraints of how much memory is available.

 

Like everything else about ENBoost, your mileage may vary - it really depends on your system, and particularly your MB bus / PCIe / RAM / VRAM clock speeds.

 

Jafin16 certainly seems to know his stuff, and Boris has rarely come back to correct Jafin16, so his explanations can be trusted. That doesn't stop me from reading through every post Boris has made about each ENBoost feature / enblocal.ini setting to gather what the maker himself has said on the topic (though it does require so real reverse-English translation skills to really understand it all!)

 

2. I also run SKSE 1.7 alpha, and implementing sheson's memory patch fix with it. I don't see any difference in stability regardless of how I set ExpandSystemMemoryX64.

 

What I can tell you is that the setting definitely changes where some memory heap blocks are allocated in TESV.exe's memory address space. I've used the VMMap utility to confirm this - even the blocks affected by sheson's fix are moved to the top of the address space when the setting is enabled (and thus matching Boris' description of what it does.)

 

However, I absolutely refuse to agree that the setting causes any incompatibilities with SKSE 1.7.0, and would suggest that it's much more likely due to something else - perhaps Race Menu (which is known to drastically increase block 1 heap usage) or another SKSE plug-in-based mod? But then, I also use Race Menu - no problem, so go figure.

 

Bottom line, it's hard to know how I'm avoiding the crash with ExpandSystemMemoryX64=true when I don't get one in the first place. Honestly, I have investigated quite deeply - even asking questions of MS system engineers into what this feature does, and you are not missing out on anything performance-wise by leaving it disabled. Trust me. Just set it to whatever doesn't seem to cause more crashes, and forget about it.

 

What did I say above....? Oh yeah, again, your mileage may vary.

 

3. By limited VRAM, I'm sure he means actual physical video RAM. Which I've only got 1GB of. SO Boris' comment doesn't really apply to you. General consensus as of late with ReservedMemorySizeMb is to try 128 or 256 for a 4GB vcard setup like yours. That setting seems to have much more correlation to reproducible crashes than ExpandSystemMemoryX64 does, from what I've read. But... if you're hitting your (physical) VRAM limit often, you must be using pretty hi-res textures, so then you may actually want to try setting ReservedMemorySizeMb to 512. Maxing out on VRAM also means you should consider setting VideoMemorySizeMb higher than 4096, to extend what is used as VRAM into system RAM (in enbhost.exe, as jafin16 explained.)

 

 

To throw my hat into the ring on that VideoMemorySizeMb question - I am running with 4095 myself, had been using 3072 before, and have seen no difference, but when I had tried setting it to 1024 or even 1000 as some suggest - lag & stutter galore!

 

Very interesting to note - with my 32GB of system ram, if I set AutodetectVideoMemorySize=true (which overrides ANYTHING you have set by VideoMemorySizeMb by the way) then when I check in the ENB GUI, it tells me ENBoost decided my Video Memory Size is between 15-17GB, depending on what else is running when I start Skyrim.

 

This shows that the previous 10GB limit on the RAM+VRAM-2048 equation no longer applies, due to the new 128GB limit increase that Boris added (in 0.250, I think it was). Also, it shows that AutodetectVideoMemorySize does not just set the value to be the same as your physical VRAM size.

Edited by keithinhanoi
  • +1 4
  • 0
Posted

Outstanding research Keith. Sounds like the simplest solution may be to just set autodetect=true and assume it all goes to plan. I really appreciate your diligence in chasing down answers to these questions, and then posting them here for the community's benefit (sounds corny, I know).

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines, Privacy Policy, and Terms of Use.