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!

[kyd462]

 

I have used these settings for about 2 weeks straight and have considerably improved gameplay in regards to what most people recommend.

 

[MEMORY]

ExpandSystemMemoryX64=true

ReduceSystemMemoryUsage=false

DisableDriverMemoryManager=false

DisablePreloadToVRAM=false

EnableUnsafeMemoryHacks=false

ReservedMemorySizeMb=2147

VideoMemorySizeMb=8192

EnableCompression=false

AutodetectVideoMemorySize=false

 

This posters recommendations are wildly different from anything else I've seen on the ENBoost topic (and I've been researching the heck out of this for entirely too long at this point), yet I figured "what the heck!" and tried it anyway since it doesn't seem anyone has a real firm grasp on the proper settings to use. I had to add my two cents to the mix and say, this actually produced the most consistent results for me. I understand his settings essentially negate ENBoost, but still... my game still ran smoother than it did without ENBoost, so there may be something to it. But it's still not as smooth as it should be. 

 

I apologize for the wall of text, but I really would like some help learning what these settings actually do, and how to begin honing in on the proper settings for my system. Hence, here is all the system and configuration info I could provide off the top of my head to paint a clearer picture. I see far too many "these are my settings" posts, and far too few "this is the system I'm running" details to go with them. It makes all these numbers seem so arbitrary.

 

SYSTEM:

Win 7 64bit

WD Caviar Blue HDD 7200rpm

CPU: AMD  FX 8320 8-Core 3.5Ghz

GPU: Nvidia GeForce GTX 660 2GB

RAM: GSkill 16Gb (8Gbx2) 1600

 

SETTINGS:

GPU is handling Vsync + Triple Buffering + 60fps Frame Limit + 16X Anisotropic Filter + Ambient Occlusion

Skyrim is handling Antialias @ x4 MS

ENBoost is handling... I'm not sure yet... allegedly memory management in some way...

 

Skyrim.INI and SkyrimPrefs.INI are Vanilla Ultra with only minor tweaks for UI, VATS, etc

 

[Papyrus] - What SkyrimLauncher.exe produces as DEFAULT SETTINGS.

fUpdateBudgetMS = 800.0

fExtraTaskletBudgetMS = 800.0

fPostLoadUpdateTimeMS = 2000.0

iMinMemoryPageSize = 256

iMaxMemoryPageSize = 512

iMaxAllocatedMemoryBytes = 2457600

bEnableLogging = 0

bEnableTrace = 0

bLoadDebugInformation = 0

bLoadDebugInformation = 0

 

[Papyrus] - Current Settings

fUpdateBudgetMS = 1.6

fExtraTaskletBudgetMS = 1.6

fPostLoadUpdateTimeMS = 2000.0

iMinMemoryPageSize = 256

iMaxMemoryPageSize = 512

iMaxAllocatedMemoryBytes = 115200

bEnableLogging = 1

bEnableTrace = 1

bLoadDebugInformation = 0

bEnableProfiling=0

 

Installed SKSE 1.7.1 Scripts + 512mb mem Patch and Steve40's ScriptFixes

 

LOAD ORDER (Bare Essentials):

Skyrim.esm

Update.esm

Unofficial Skyrim Patch.esp

Dawnguard.esm

Unofficial Dawnguard Patch.esp

HearthFires.esm

Unofficial Hearthfire Patch.esp

Dragonborn.esm

Unofficial Dragonborn Patch.esp

HighResTexturePack01.esp

HighResTexturePack02.esp

HighResTexturePack03.esp

Bashed Patch, 0.esp

 

A) enblocal.INI (Based on CovertSlinky's recommendations)

[MEMORY]

ExpandSystemMemoryX64=true

ReduceSystemMemoryUsage=false

DisableDriverMemoryManager=false

DisablePreloadToVRAM=false

EnableUnsafeMemoryHacks=false

ReservedMemorySizeMb=2048 ;Set to exactly 2Gb (full VRAM)

VideoMemorySizeMb=16384 ;Set to exactly 16GB+2GB-2048)

EnableCompression=false

AutodetectVideoMemorySize=false

 

B) enblocal.INI (Based on Nvidia 2Gb INI that came with old ENboost)

[MEMORY]

ExpandSystemMemoryX64=true

ReduceSystemMemoryUsage=true

DisableDriverMemoryManager=false

DisablePreloadToVRAM=false

EnableUnsafeMemoryHacks=false

ReservedMemorySizeMb=256

VideoMemorySizeMb=1920

EnableCompression=true

AutodetectVideoMemorySize=false

 

I've tried installing STEP EXTENDED (using medium options when available) and it just bogs down my performance to near unplayable (30fps and below with increased macro-stutter during cell loading), despite meeting the requirements. So my tests have been whittled down to STEP 2.D until I resolve the root of these performance issues.

 

After far too many tests just to make a game more stable to play, I've noticed hardly any difference no matter what settings I throw in there. However, CovertSlinky's recommendations have indeed given me the best reduction of macro-stutter (sudden stops when turning corners and loading new areas). This was all I was really after in the first place. But the trade-off is that the game just "feels" a little less smooth. By all other accounts it actually is more smooth though. It's strange.

 

Oddly enough though, stats don't lie, and setting ReduceSystemMemoryUsage=false does seem to revert system memory use back to default. Making me curious if this is just placebo, or if there is more to enbhost.exe than just off loading ram use to vram. Does it simply improve the process of swapping between the two if you don't take advantage of it's ability to dump everything onto the GPU?

 

I'm very confused because no matter what I never come close to hitting even 400mb of the 512mb ceiling enabled with SKSE. Even if I spawn 50 Windhelm guards 50 Whiterun Guards and 4 dragons at Windhelm Docks I don't use more than 400mb of that first block, and Performance Monitor backs this up. It shows plenty of headroom between my peak VRAM usage and the 2GB limit of my card... yet I still experience FPS drops, load-stalling/stutter, pop-in, etc... My HDD is hardly used at all too. That is odd to me.

 

I thought ENBoost was designed to help with these issues, but it's so confusing to figure out how to configure it and what the settings actually do. I know many people say "results will vary from system to system, play around with it and see what works." But I can't subscribe to that mentality blindly. It's a program with specific parameters. Someone has to know how it's supposed to be used correctly, and how to interpret the configuration to adapt to other systems. The overall "effect" may vary, absolutely! But not the settings. That should be straightforward, A+B=C.

Edited December 10, 2014 by kyd462

[TechAngel85]

https://wiki.step-project.com/Guide:ENB#ENBoost

[kyd462]

Thank you for your reply, Dragon King. I've returned to that guide many times in the last couple weeks, but my primary issue still remains. I believe the inevitable answer is that macro-stutter and pop-ins during cell-loading is just an unsolvable fact of Skyrim's engine. Neither ENBoost nor SKSE provides the solution for that, so I will look into what INI settings may achieve, like in previous bethesda games.

 

EDIT:

 

Significantly improved performance and reduced stutter/pop-in with the following settings. Namely the Skyrim.ini settings combined with enblocal.ini settings. System Specs above... Performance especially improved during combat, with only occasional minor stutters when NPCs switch from passive to aggressive. It's easily repeatable on NPCs specifically coming out of idle behaviors mostly. Probably just a quirk of the engine. Occurs with or without any adjustments to settings.

 

Skyrim.ini 

[General]

iNumHWThreads=8  ;Telling the game I have 8 cores wasn't enough alone, but needed for below.

 

iHWThread6=6   ;Default has 6,5,4 sharing work with iAIThread2HWThread.

iHWThread5=6   ;So I offloaded that work to 6 (aka '7' based on sequence starting at 0).

iHWThread4=6   ;The reason being that allegedly Bethesda accommodates up to 4 cores.

iHWThread3=4   ;Since '5' is nowhere to be found in defaults, I didn't want to chance using it.

iHWThread2=4   ;I tried several variations. Only measurable change is to threads 6,5,4

iHWThread1=4   ;By offloading 6,5,4 to a new core, Threads increased by ten, and performance improved.

 

iAIThread2HWThread=3   ;Again, no measurable difference by changing these at all

iAIThread1HWThread=2   ;I kept them included at defaults to keep them the same.

iRenderingThread2HWThread=1

iRenderingThread1HWThread=0

 

bRunHighLevelProcess=1 ;Very slight boost when other applications are running.

 

;The following are purely speculative and based on 'feeling'.

;When all are disabled the game feels more stuttery and sluggish to me.

;Especially true when using the above changes. 

 

bMultiThreadMovement=1

bUseThreadedParticleSystem=1

bUseThreadedBlood=1

bUseThreadedMorpher=1

bUseThreadedTempEffects=1

bUseThreadedTextures=1

bUseThreadedMeshes=1

bUseThreadedLOD=1

bUseThreadedAI=1

 

uStaticNeverFade=1 ;This was recommended elsewhere. I honestly can't tell if it has any effect.

 

bUseHardDriveCache=0 ;Increased HDD access when enabled, bytes used unchanged. Impact is nil

 

[Decals]

bDecalMultithreaded=1 ;Same as bUseThreadedETC... above

bForceAllDecals=1 ; Slightly less stutter frequency, but a little more 'punch' when it does happen.

 

Everything else is default except for Interface, VATS, Gamma related settings.

 

ENBlocal.INI

[MEMORY]

ExpandSystemMemoryX64=true

ReduceSystemMemoryUsage=true

DisableDriverMemoryManager=false

DisablePreloadToVRAM=false

EnableUnsafeMemoryHacks=false

ReservedMemorySizeMb=512   ;1/4 VRAM, STEP Extended installed. All is well. Avg 50-60fps in most areas.

VideoMemorySizeMb=16384    ;Standard RAM+VRAM-2048 suggestion. Makes no difference I can observe.

EnableCompression=false         ;This particular setting is critical to my smooth experience*

AutodetectVideoMemorySize=false

 

*With compression enabled, I experience a lot more stutter, and an overall laginess like my hardware is struggling, despite the logs and graphs suggesting everything is fine and still well under load capacity. Still plenty of room to operate safely as well with it turned off.

 

This combination runs smooth as silk, apart from infrequent minor stutter caused when loading cells and large amounts of assets, but those areas are isolated. The area around Whiterun and that entire field is still fairly choppy to ride through on horseback, but getting away from there reduces my load-stutters almost completely. I guess there are some areas in the world (like all bethesda games before it) that are just poorly optimized and will cause hiccups now and then.

 

 

[EDIT:] My test run is as follows: 

 

From a Clean Start Save (No Mods / Essentially STEP 2.D up to Unofficial HighRes Patch) outside of the cave immediately after completing first quest out of Helgen. TGM + Player.setav Speedmult 200... Switch to 3rd person with two drawn swords (because it looks cool running like that. It really serves no purpose. lol). Sprint to the nearest bandit cave, kill the bandit, kill the wolves, run through Riverwood, cross the bridge, round the corner to the right.

 

[NOTE] Whether it's 100% vanilla, SKSE mem patched, ENBoost, 300 mods... doesn't matter. There will be two brief stutters. One immediately after rounding the tree stump, and another shortly after. Not surprisingly, two wolves appear down the road chasing a bunny after that. I'm 99% sure that is a scripted event. Doesn't happen often with other encounters. [/] 

 

Kill the wolves, sprint forward, catch up with imperials walking a stormcloak prisoner. Free the prisoner, give him loot from Helgen, kill everyone (why not? it's just a test). Sprint to the stable, steal a horse and ride it all the way through Labyrinthian, right off the ledge (killing the horse). Run around outside a bit, go back in and fight some trolls, then sprint back towards Whiterun.

 

[NOTE] Whether it's 100% vanilla, SKSE mem patched, ENBoost, 300 mods... doesn't matter. Riding a horse from Whiterun to Labyrinthian is the most stuttery experience I have had no matter what. It's a good trip to take though, because it tells me right away if anything I've done has improved my core experience issues at all or made them worse.

 

Sprint down the road and across the bridge near Whiterun. Fight the guard on the bridge, kill him, but don't kill the other that comes to help so I leave a hostile NPC instance in a cell. Jump into the river and sprint and swim to the bandit fort. Kill everyone, jump off the bridge into the water, sprint and swim downstream all the way to Windhelm docks. Spawn 30 Windhelm Guards, 30 Whiterun Guards, 20 Necromancers, and 4 Dragons... Fight a laggy 18-35 fps battle for a good while until everything is dead. 

 

TCL + Player.setav Speedmult 600... Sprint (or fly) back up the river to Riverwood (because that whole set of transitions from cell to cell and all the waterfalls love to crash). From Riverwood, speed back to Whiterun. Go inside, speed around, leave. Go back in, leave, go back in, leave. (This is aggressive. Must want the game to crash!) Spam menu and inventory and exit before anything loads like a crazy person.

 

After this, I try to fly to all the edges of the map, major cities, buggy areas especially, back and forth, swinging view quickly to try to catch the engine and hardware by surprise. If I can do this for a solid 5-minutes without completely freezing or crashing, then I boost the speed to 1000 and return to spots that froze a little longer than others. I do this for another 5-minutes. If it doesn't crash or completely freeze, then I dual cast fire spells flying as close to the ground as possible for another few minutes (sometimes the game crashes like this no matter what settings, but that's a lot to ask of it).

 

If all goes well, then I go to Rorikstead, set speed down to 300, tcl back on, and run back to Whiterun, down the river again to Windhelm, and swim onto the docks. I take that path so often because it crashes so often (before at least).

 

[NOTE] Just today I managed to complete this test, only this time I had the full STEP Extended lineup installed. It was a glorious moment when I made it back to the docks for the last time and didn't crash or freeze up before even making it to Whiterun. 

Edited December 17, 2014 by kyd462

[z929669]

Thanks for the feedback ... can you confirm what settings are key? You can do this by commenting individual changes you made to the INIs and testing on same sequence in game.

[kyd462]

Thanks for the feedback ... can you confirm what settings are key? You can do this by commenting individual changes you made to the INIs and testing on same sequence in game.

No problemo! Done and done! Edited the post with settings comments and a detailed run through of my test routine.

[TechAngel85]

There's nothing unexpected or "new" from your result for the memory settings. They've been well tested and what we have in the Guide is the result of that testing from several members. Keithinhanoi is the most knowledgeable person I know with these settings and much of his knowledge I suspect comes from testing on being on the ENB Dev forums.

[keithinhanoi]

Yeah, no big surprises in your findings, kyd462, from everything I've read and my own experiences.

 

I used to use all the multi-core / multi-thread .ini settings when I was using my iMac with a quad i7, but then after some discussions with the author of Queue, the author of SSME, and some deep forum scouring, I found that all the settings with HWThread should only be used if you've got a processor with 6 or 8 physical cores. The last update of Skyrim was definitely quad / duo core aware, and multi-threaded, so no other tweaks are needed.

 

However, the bMultiThreadMovement and all the bUseThreaded_xxx settings, despite the apparent "boost" they give to game responsiveness, shouldn't be used, because TESV.exe already has all processes set as multithreaded that can be.

 

By turning all the "threaded" options on, you are playing with fire because they run the risk of causing race conditions with threads that are dependent on each other, which leads to more frequent memory exception errors - in other words, more CTDs at very random and inopportune moments. On this point people could argue about it until the end of time, but I always go back to the logic of if they really made things work better without any crashes, those settings would be on by default. Just remember if you experience more frequent random CTDs, try turning these ones off and play for a while to see if things "calm down."

 

Otherwise, if you are looking for settings to make your experience smoother and less "stuttery" and CTD-free, I'd suggest more testing with the following:

 

ExpandSystemMemoryX64=true

Setting this to false reduces CTDs for some people. It will not, however, make things work any faster. I have done extensive research on what this setting does, and all it does is change where in TESV.exe's memory space certain heap blocks are allocated, to the "top" of the memory space if set to "true." The particular Windows system code that accomplishes this was only ever meant for testing application compatibility on 64-bit systems. 

 

ReservedMemorySizeMb=512

According to Boris, in more recent ENB binary releases, things have been optimized such that this value can be reduced from the 512MB that was previously recommended. Try 256 or 128 to see if there is less (or more!) stuttering.

 

VideoMemorySizeMb=16384

The big question with setting this value so high is whether your system RAM ever actually gets used as VRAM while playing in-game. Boris has always maintained setting this to be the same as the amount of physical VRAM is the best way to go. In your case it would be 2048 (2GB, same as your VRAM). So that's something to try, if you haven't already.

 

But if you use higher resolution textures, and usage of your 2GB of VRAM is getting maxed out often with this set to 2048, then it's better to set this above 2GB. How much higher shouldn't matter much with the amount of RAM you have. If you only had 6 or 8GB then it would be a concern. But I highly doubt that you'll ever see even 8GB of RAM being used by several instances of enbhost.exe, so there's little danger of using up all available memory.

[kyd462]

Thanks for your informed response, keithinhanoi. I removed the thread settings from my INI, and adjusted my enblocal.ini settings according to your recommendations. My performance and overall smooth experience was significantly worse. Increased cell load stutter, increased overall stutter, terribly stuttery during combat. It was worse than if I'd simply removed ENBoost altogether. I would go so far as to call it unplayable.

 

By "stutter" I hope I'm referring to what I think everyone else is: Sudden and brief stops/stalls (like a frame or two was skipped or paused briefly) while moving around the open world. It almost never happens indoors. As I've said above, there are specific areas that will always do this regardless of any settings, but the effect can be increased with certain settings, never decreased it seems. I call this "load-stutter" because it only happens when assets are loading (visibly apparent by scenery and NPC fade-in and pop-ins, sudden changes in NPC behavior, etc...)

 

Now, there is another sort of "stutter", the kind I would usually use the term for (and occurs in many other games with improper settings or hardware that isn't up to the job). That's when it feels like only every other frame is being rendered. It's hard to look at without getting dizzy, input is laggy, overall experience feels like the game is struggling to run. I get this sort of effect with the settings you recommended in addition to the other variety of "load-stutter". Previously, the game wouldn't even come close to running like that until I'd spawned my 60 guards and 4 dragons at the docks.

 

I know the first inclination would be to assume it's perhaps a hardware issue, but this system is in perfect running condition, and has no problems running anything else I throw at it but this game. For work, I'm constantly running Adobe Premiere, After Effects, and Maya simultaneously while rendering complex scenes and/or video (typically out of 2 applications at a time with live-preview enabled) and watching an HD movie and browsing the web without even a hiccup. My rendering progress bar smoothly tracks from left to right without ever stopping to think. If swapping from Ram to Vram to Hard drive and any combination of them had a bottleneck somewhere I would have noticed by now. But this game... ooooh... fine-tuning the performance of this game has become an obsession. lol

I'd like to know more about the ideal performance scenario for Skyrim to give it the best conditions to perform under. Is it more efficient when RAM is being utilized at a higher capacity than VRAM or vise verse? Is it best at swapping smaller amounts of data, larger amounts? I can shift the balance between RAM and VRAM on the performance graph quite a bit, but what does Skyrim like best? Under the "perfect scenario" I'll just have to accept that the game runs like crap sometimes all on it's own and just can't be helped. But I'm encouraged to keep trying anything because I read for some people certain things have made their game "completely smooth", that stutters are "practically non-existent", or that "loading pop-ins etc aren't even noticeable anymore". Is this just cognitive dissonance? Placebo? hahaha

Edited December 12, 2014 by kyd462

[z929669]

Nice test run ;)

 

I cannot attest to any of the m-thread settings, but I will check out EnableCompression enblocal setting, because I know there are variable results with that one. Agree with keith though that most of the skyrim.ini settings should be left at default unless there is some reason to change them (i.e., testing). We should continue to recommend what we always have, remaining cognizant of said changes above just in case for testing behind the scenes.

[Aiyen]

First and foremost you got to remember that the only reason skyrim can even use more memory in the first place is due to a hack... it is not native support. There is most likely a bottleneck loss in that most of the data is stored in a separate process and then have to be accessed. 

 

When you run maya etc. then they have native 64bit support, and dx11 support, and... lots of other optimization algorithms that most likely run way better then an old gamebryo engine based game ever will. 

 

Finally there is the whole "its a game deal" The game was designed around the old consoles, and never meant to handle this, hence many areas etc. are in no way optimized. For this reason you can run with 4096 shadow settings fine in some areas.. but in others it will demolish your FPS regardless of your card.. simply due to that area not being optimized properly. 

 

As for stuttering and popin... In my experience then we all have a different interpretation of what it is and how bad it is before it is noticeable. I am fairly sure people who say they have no stutters at all have just not looked hard enough or got a higher threshold for when something is a stutter. Even the vanilla game on the most god like machine today will be able to produce stuttering and popin. All open world games suffer from this. You can load the same scene 100 times and perhaps it will only produce a stutter 2 of those 100 times.. but still. 

In general if you have more memory you will be able to cache more of the game, and hence reduce stuttering to a bare minimum. I do enjoy from that, I have rather bad long initial load times, but once it is done once then every consecutive load is practically instant. 

 

Scripts cause stuttering as well. If you do use mods such as enhanced blood, spell on hit effects etc. etc. then they will be able to produce stuttering quite readily while in combat.. combat is one of the most intensive processes the game does, so always treat that scenario differently than just walking about the game with AI toggled off. 

 

Speaking of that. When you want to test stuttering then I normally disable all AI and just walk about and run about.. this will test general texture loading performance, and show bottlenecks due to memory rather easily. 

 

For combat testing I normally just spawn 10 badguys.. and 10 other guys  and let them fight it out. Or just go to solitude and spawn a couple of dragons and let them loose on all the NPC´s. Spell effects, combat effects etc. it is all good fun to both watch and it will show if scripts are causing a bottleneck with the CPU and/or memory. 

[kyd462]

Still only testing with Vanilla Skyrim (no mods whatsoever).

One thing remains consistent throughout all my tests: I can increase stutter, but I haven't been successful with reducing it yet. By reduce, I mean beyond a baseline I've observed while running several dozen tests with vanilla skyrim, default INI, no ENBoost files, and only the SKSE mem patch enabled. There are specific areas (in fact specific coordinates within said areas) that always produce stutter, every time. It's not a matter of 2/100 times. It's reproducible every time. Some of these areas are mentioned in one of my previous posts above.

Essentially, the goal of my testing now is to determine what, if anything at all, can reduce or eliminate these particular instances of stutter. So far, I've only discovered the ability to increase frequency of stutter to areas which are completely unaffected in vanilla Skyrim. The only observable benefit to using ENBoost that I've seen so far has been the total elimination of CTDs and freezing (with one exception where I pushed the game beyond any reasonable limit.)

I recently stumbled onto https://www.nexusmods.com/skyrim/mods/48387/ which a vast majority of commenters seem to agree works wonders for solving their issues with various types of stutter and CTDs. I'm currently testing these settings out in combination with a baseline enblocal.INI (128/2048) and standard SKSE mem patch (768/256).

I'm curious to know if anyone has thought about or tested the effects of iPreloadSizeLimit or iMaxAllocatedMemoryBytes in Skyrim.INI in conjunction with ENboost? I know STEP in general has a strict "Do not mess with INI files whatsoever" policy, but these do seem like the sort of settings that could have a dramatic effect combined with ENBoost.

For instance: Could iPreloadSizeLimit actually be set too low by default for ENBoost to have any real excess of data to manage if one isn't using any mods. And if that's the case, could the baseline performance of Skyrim be improved before/without the use of mods.

Imagine if it were possible to configure a perfectly smooth-running Skyrim experience. That sort of environment would be a huge deal for testing the performance impact of mods, because if if anything changed negatively you'd know for certain it was the mod that caused it.

Anyway... I understand most players have probably moved on by now, or soon will, but I'm still on a mission to learn what I can to get the game running as best as possible before committing to a 300+ hour playthrough. :)

 

[Aiyen]

The reason for the "do not mess with the ini´s approch" is quite simply that in 9/10 cases people mess things up. The main issue with ini tweaks is that there are not any golden standard that just works for all... except the base values. 

 

Just like ENBoost settings depend on the hardware up to the point where manufacture and the quality of the components are concerned.. then so does the ini settings. Hence people will say "but person A says it works wonders for him/her" and use that to defend that their ini tweak should work... when in fact it wont work for their computer. 

 

Anyways I digress. Back on topic! 

 

Some spots in the game just aint optimized at all. Short of going into the CK and fix those locations one at a time then you are most likely going to have to accept a middle road in terms of settings. 

 

I have also tested out the recomendations at that site, but it is my impression that the fella does not in fact run with an ENB on. But I have noticed a few people I know do say it works good. However again I think it depends on the setup and hardware. For me personally I see no real difference either or. Especially the whole "you might get more FPS" I am highly skeptical about. But I guess in the case of a memory bottleneck on computers with less memory it might be a thing. 

 

I have managed to get a stable ugrids 7 setup before... but that was with some compromises in the texture department.. but again 2Gb of VRAM will get you far, but not that far! So I would not be surprised if 4Gb of VRAM would allow you to play around with the higher ugrid settings and a decent selection of 2k textures. 

 

As for the ipreload and memory allocated settings, then I have never experienced or seen anything to suggest that they where the reason for improvement. In my experience ENBoost and the Shenson memory patch does vastly more for the stability and ability to get ugrids 7 stable then those. 

 

However again my system is just one among many, so do feel free to experiment away and report any findings back! For now I decided to put them back into my current list just for the heck of it. I am almost at the point of stress testing it anyways. 

[kyd462]

Quick question. I'm nearing the end of my testing. I've exhausted nearly everything at this point lol. This is sort of off-topic, but it's related to helping me test the effects of INI settings combined with enblocal.ini settings, so I hope it's not too far off the mark.

There's several sources for tweaking INI settings, and not all of them are consistent about what settings go where. My question is; does it really matter where anything goes? 

hahaha... I know it's logical that it should matter, but there's quite a bit of speculation out there about whether Skyrim.INI and SkyrimPrefs.INI are simply combined during runtime anyway. Essentially read and loaded on top of one another. Some even suggest literally working in one, then copy-pasting the entire contents into the other. This actually works perfectly fine for Fallout and Fallout NV, but I wonder if it holds true for Skyrim. So I'm curious if anyone has any insight about this or if anyone's tested it thoroughly.

 

Also, for that matter, do the [sECTIONS] matter? Some say to put such and such under [General], while a default INI will list these under [Display] or somewhere else. Etc etc... For an INI, I see no reason for sections other than visual aid when editing the file manually. Most applications use parsing algorithms to find the value of specific settings. Coding to search for sections and then the settings seems too redundant. I'm tempted to remove the sections altogether and alphabetize the file just to see. I would bet it makes no difference, but many people say to put a line specifically after X, or between X and Y, or at the beginning or end of [XSection].

What I'm most curious about is combining the INIs though. If one really could just combine the two INI files and copy-paste the contents to either or, it would make testing and tweaking a helluva a lot less tedious if/when experimenting with INI settings.

Edited December 18, 2014 by kyd462

[GrantSP]

Welcome to the bizarre world of ini tweaking.

Have a look at the recent vsync discussion here at STEP to see whether one ini takes priority.

I'm of the view the sections do matter though you make a good argument against it. I'll think about that a bit more.

[keithinhanoi]

It never ceases to amaze me that the myth of iPreloadSizeLimit and iMaxAllocatedMemoryBytes continues to this day.

 

These are the modern equivalent of snake oil for Skyrim.

 

iPreloadSizeLimit only sets how much memory is used to pre-cache the Bethesda splash video shown when you start Skyrim.

 

It has no effect whatsoever on how much RAM is allocated to anything else in the game. TESV.exe is a 32-bit LAA (large address aware) executable, which means it is capped at 4GB of memory addressing. System and other dynamically loaded libraries (.dll) either take up 2GB on 32-bit Windows (by design, and true for all programs), or roughly 900MB on 64-bit Windows. That's where the 3.1GB memory limit that you hear about so much comes from.

 

The iPreloadSizeLimit can't magically grab more RAM for TESV.exe to use, nor does it change how much memory of the available 3.1GB can be used for anything other than the opening video - and that is also capped at a very low amount of memory, like 32 or 64MB (can't find source ATM.)

 

Don't believe me?

 

First, try reading this post by Purple Lunchbox, who has been part of the SKSE team.

 

If that's not enough, then try looking "under the hood," inside Skyrim's memory allocation itself.

 

To do this, download and use the amazing free VMMap utility from SysInternals. This utility allows you to view exactly how a program is making use of it's entire memory address space. Fire up SKSE to launch Skyrim, and during the delay until Skyrim starts, open VMMap and select TESV.exe as the program to trace. You can save a snapshot of TESV.exe's current memory address mapping, and then quit, change iPreloadSizeLimit to something much bigger and then run Skyrim again and take another snapshot with VMMap. You should so no or hardly any change.

 

No, there are only two thing that can change how TESV.exe uses memory and those are

1. ENBoost, which relocates some of the cached texture / 3D mesh data that would normally get written in TESV.exe 3.1GB memory space over into available VRAM (and RAM if set up as such), and
    
2. Sheson's heap memory block fix, which does actually tell TESV.exe how much memory to set aside for certain kinds of cached data (mostly to do with loading / unloading of cells as you move around).

And iMaxAllocatedMemoryBytes? Directly from Bethesda's Creation Kit wiki page on the Papyrus settings in Skyrim.ini:

This is the maximum amount of memory the VM will allocate in total for stack frames. If an allocation would push memory usage over this limit, the VM will instead wait for more memory to be freed. Increasing this value may improve performance in high-stress situations with lots of scripts running, but will use more memory. Note that it is possible to exceed this value temporarily while loading a save game due to slightly different allocation ordering.

 

Max: 2147483647 (2GB)

 

Default: 76800 (75kB)

 

WARNING: this setting is for stack size not heap size, so there is no reason for setting this to a huge value even though it is possible. Increasing iMaxAllocatedMemoryBytes to values much larger than default can cause stack thrashing (stack buffer overflows), intermittent game stuttering, erratic game behavior and CTDs. Stack thrashing will produce stack dumps in the Papyrus log, similar to the example below. The dumps can be very large if many scripts are running, producing a very large log file.

I'm not even a programmer, and it takes 5 minutes of Googling to figure out that increasing the memory just used for the stack used by Papyrus to 2GB is absolutely preposterous. The amount of memory needed for the stack of such a simple virtual machine is minuscule. At worst, you are telling TESV.exe to reserve memory that is needed for things that actually do take up a lot of memory, like cached texture data, and that will not help at all with any stuttering.

 

If you're really looking for mod pages that are good guides, my advice is to look here.