Skyrim Memory Patch - fixing ILS, uGrids CTD, freezes

[Jon9101]

Going to try out Sheson's new logger today and report back some info later today. Interestingly enough, I was going by Shesons guidelines in the loggers Nexus page, and I read that the second block shouldn't be set to higher than 256. I usually play with the first block on 768 and the second on 512. Setting it back to 256 CTD's me at the main menu, hmm.

[Bundy714]

Just to be clear, I was not promoting SSME in my previous posts, I really don't have a horse in this race and don't care what method of implementing Sheson's patch that people use. I was just giving my personal experiences. After reading what Daetarek and Tuoni wrote, perhaps there is a difference in how the various implementations work, I don't really know. All I have is anecdotal evidence that may be unique to my setup, both hardware and mod wise.

I would test other methods, but I'm finally enjoying playing Skyrim with all the mods I wanted to throw at it, for the first time since it came out. Right now, I'm in a "if it's not broke, don't mess with it" kind of mode, haha. As you can see, I've been extremely cautious, I haven't changed the default 512/256 settings, or ugrids.....my main goal has always been to just play the game without annoying CTD's. And perhaps luckily, I have achieved that goal.

In that regard, I've read that my settings for ENBoost are not optimal and could be "improved", but I am loathe to change or improve them because it is working so great now that I hate to rock the boat and change anything.

From what I've read in recent posts, I am not allocating nearly as much VRAM as I could/should be. Below is my enblocal.ini, that was included in the ENBoost 5.0 download from the Nexus (AMD card with 3gb vram). Now I keep reading that the current recommended VideoMemorySizeMB should be VRAM + RAM - 2048 which would be a much higher number than what I'm using. If that is correct, then I believe I should be using VideoMemorySizeMb=9216, but then I imagine that the AutodetectVideoMemorySize should be changed to false? I don't know, that's why I haven't changed it. I just used what came in the download and it works, it may or may not be the most optimal setting as far as current thinking goes. I guess I could go read pages and pages of comments and figure it out, but I've been too busy playing Skyrim.

Heck, for all I know, maybe this is why SSME is working great for me and not others?? Could that be the case? It's all a bit over my head.

[MEMORY]
ExpandSystemMemoryX64=true
ReduceSystemMemoryUsage=true
DisableDriverMemoryManager=false
DisablePreloadToVRAM=false
EnableUnsafeMemoryHacks=false
ReservedMemorySizeMb=256
VideoMemorySizeMb=2944
EnableCompression=true
AutodetectVideoMemorySize=true

[Daetarek]

Going to try out Sheson's new logger today and report back some info later today. Interestingly enough, I was going by Shesons guidelines in the loggers Nexus page, and I read that the second block shouldn't be set to higher than 256. I usually play with the first block on 768 and the second on 512. Setting it back to 256 CTD's me at the main menu, hmm.

They are indeed Guidelines, just use what works for you be aware however going to large can cause issues elsewhere, however I have run with 768/512 for a while now and mostly had no issues.

snip

Heck, for all I know, maybe this is why SSME is working great for me and not others?? Could that be the case? It's all a bit over my head.

[MEMORY]
ExpandSystemMemoryX64=true
ReduceSystemMemoryUsage=true
DisableDriverMemoryManager=false
DisablePreloadToVRAM=false
EnableUnsafeMemoryHacks=false
ReservedMemorySizeMb=256
VideoMemorySizeMb=2944
EnableCompression=true
AutodetectVideoMemorySize=true

Bundy, I loved your post at Nexus, and your posts here have been nothing but informative and hopefully helpful to people, I have nothing but kudos for you

In regards to your ENB settings, use what works best for you, I have tried all the formula's and variants and what worked for me is totally different.

I have had many thoughts as to why SSME is a problem for me and not others, varying from it being a windows 8.1, the fact i use 768/512 memory allocation, maybe my ENB settings even, i think Queued also mentioned something about the way he hooks memory and how it relates to enb could be a problem however that got lost in the sea of posts over at nexus so i can't seem to locate it.

[keithinhanoi]

@Bundy714

In enblocal.ini, everything I've read states setting AutodetectVideoMemorySize=true overrides whatever you have set with VideoMemorySizeMb=. It was added in binary 0.243 (source - Boris's post). He refers to it as auto detecting shared video memory, and added the setting in an effort to reduce stuttering when moving from interior to exterior spaces if the user used "wrong" ENBoost memory manager settings.

Probably a better confirmation that the auto detect feature overrides VideoMemorySizeMb is on the ENB Main Index page in the update for 29 December 2013: "Forgot to mention that in version 0.243 added parameter AutodetectVideoMemorySize which set video memory size automatically for ENBoost memory manager."

In contrast, ReservedMemorySizeMb sets the amount of VRAM that is not shared by ENBoost memory manager or used in its memory allocations (source - Boris's post), and is left available for dynamic resource allocations.

I've posted on the original thread announcing the AutodetectVideoMemorySize setting to ask Boris if it does indeed override, but either way, the important thing is that there needs to be a good balance between the VideoMemorySizeMb (not too low) and ReservedMemorySizeMb (not too low or high), as Boris explains in this recent thread.

I'll post back when I get an answer from Boris.

[Bundy714]

@ KeithinHanoi:
Thanks KeithinHanoi, I've always thought the exact same thing about AutodetectVideoMemorySize=true overriding whatever number I decided to plug into VideoMemorySizeMb...but that was just me thinking logically, I was never 100% sure how it actually works. (And I'm not even brave enough to ask Boris a question, lol) I just went with the provided enblocal.ini that came with the download of ENBoost 5.0 from the Nexus and "assumed" that since it came from Boris, I'd leave it alone.

We all have so many variables in the mix because we use PC's, different RAM, different chip sets, video cards, etc..etc.... Heck, I even got to wondering if my system having 8gb of system ram in single channel (one 8gb stick of G.Skill DDR3 1600) instead of most people using dual channel could make a difference?

Don't laugh at me only having one stick, it was thrown in as a freebie with the Motherboard, and when I looked into it, the difference between single and dual channel is very very small. And did I mention it was free?

@ Daetarek:
And thanks Daetarek for your kind words about my post on the Nexus. I had been drinking coffee and energy drinks to play Skyrim for 16 straight hours and was really tired, so I kind of went on a rant there. Did you notice that in an offhand way I said that some people needed to stick to consoles instead of PC's? The ignorant posts of "this didn't fix my CTD's" was just testing my patience. It gives you more ram, it does not fix your conflicting, mods......jeez. It's hard to try and help people on the Nexus because the user base is so.....what's the word for it....I better not say. I'm old, and this whole TL;DR generation gets on my nerves. If I had a dollar for every post on the ENBoost page saying "I want to use this but I don't want an ENB"....makes you want to strangle someone, they can't even be bothered to read the short description......but they can surely post a lot of stupid questions.

@ Sheson:
And Sheson.....your damn patch is a health hazard. Yes, I said it. I'm old and have heart issues, and I've found that if I sit in a chair for 12 to 16 hours straight playing Skyrim, because it won't crash now, that my feet and ankles swell up something awful.

[ENBSeries]

VideoMemorySizeMb is ignored when AutodetectVideoMemorySize=true is set. In this case mod trying to preallocate as much video memory as possible to detect it size, i tried that in some previous versions also, but own d3d memory manager stop working properly after that, because it's not designed for memory above 4 gb, so in 0.243 i starting another device to read that information, then destroy it (how this will affect other software like browsers or Optimus, i'm curious).

[keithinhanoi]

@Boris

Thanks a bunch for clarifying that so quickly! But then that leads me to another question:

If Video Memory Size is Auto-detected, will it be set to the same as the max capacity of your video card's VRAM - or is it set to VRAM plus some amount of system RAM?


@Bundy714:

No worries - but regarding just leaving enblocal.ini, you know that old saying about when we assume something - "It makes an..."?

Allow me to point you (and others) to some good information on the ENBoost settings:

Although a bit outdated, there's this quite important post from Boris that explains most of the ENBoost settings in response to an earlier post by Phinix (of Phinix Natural ENB fame).

Based on that and later information he got in the forums here, Phinix has added some very helpful comment lines to the enblocal.ini included in the Phinix Natural ENB download. I recommend taking a look at this to hopefully clear up what those settings do. Interestingly, there are no comments above AutodetectVideoMemorySize.

Also, RE: your post on the SSME comments thread - although I totally agree with what you said there, I think it's also important to point out that using TES5Edit to its fullest extent as a tool is also not going to prevent all instability you experience in your game. Most of what I use it for is to fix so called "incompatibilities" between mods, where changes made by one plugin are overwritten by another later in the load order.

Other things that can cause crashes, for example, are bad mesh edits - often totally accidental / unintended by mod authors, but it requires keeping up on the comments thread of every mod you install or even update. Two recent instances of this from my mod list include SkyFalls and SkyMills and Vivid Landscapes - Rocking Stones and Mountains Parallax.

Yes, it's a pain to have to read through those comments on Nexus and separate the wheat from the chuff, but a necessary evil.


@Daetarek:

I can point out the information from Queued about the way his d3d9_42.dll works, because I asked him very specifically in an effort to understand to what extent its method of applying sheson's patch is different from the modified skse_steam_loader.dll.

1. My question to Queued regarding the method of using forwarded exports to SSME's d3d9_42 proxy libary.

2. Queued's reply.

3. My reply asking for clarification and asking about CTDs I've been getting loading savegames which refers to d3d9.dll (maybe ENB or the original library?)

4. Queued's second reply

5. A later post by Queued in response to one user getting the error 'The procedure entry point D3DX9_43.#148 could not be located in the dynamic link library d3dx9_42.dll'. Here he explains that both SSME and SKSE use forwarded exports to a proxy library, but for a small set of people Skyrim won't start with SSME's d3dx9_42.dll in place.

Please note that I have since gotten a CTD loading a save game (as described in #3 above, and in this forum thread some days ago) - once - while using the SKSE 1.07.0 alpha build. So SSME can be ruled out as a possible cause of that memory exception error.

Since I have started recording every single CTD/freeze and keeping crash dump files in my testing, I can safely say that, on my system, I otherwise have not seen any lower / higher stability in Skyrim using SSME as compared to the new SKSE alpha build or the Phinix VS2008 compile of skse_steam_loader.dll (which has since been taken down on the request of SKSE's authors.)

This is to say that I continue to see CTDs and freezes which apparently are not related to the block 1 allocation issue, regardless of which implementation of sheson's patch I use.


Finally, Bundy714 has inspired me with his (polite) rant, so...

@anybody trash-talking the SKSE alpha build implementation of sheson's patch

[start rant] I just don't know why so many people seem to think something has been done wrong with the SKSE alpha build's implementation of sheson's patch.

Sheson himself said that the actual default number allocated for block 1 - before his patch is applied - is 512MB.

Then he raised it to 768MB, to see a 512MB allocation in VMMap. In his source code it's there - 0x00000300 (= 768). Same thing in SSME's .ini - 0x00000300.

So, again, there is nothing wrong in the SKSE implementation. It's doing exactly the same thing. They're just making the user enter in the actual number used to patch TESV.exe's code, and in VMMap you still see 256MB LESS being used, which is NORMAL (just as sheson has explained.)

Also, their whatsnew read me notes state very clearly what lines need to be added to the skse.ini, and those lines and the names used to refer to blocks 1 & 2 are different from all other other implementations of sheson's patch (Daetarek's variant, SSME, Neovalen's variant, etc.) Besides that, information about where skse.ini needs to go is readily available. So why is it so difficult, and a problem.

Not reading. That is the problem.

[/rant]

[ENBSeries]

keithinhanoi
AutodetectVideoMemorySize=true set size of VideoMemorySizeMb internally to size of shared VRAM, which is physical VRAM + RAM used by display driver.

[SkyrimSuzerain]

keithinhanoi
AutodetectVideoMemorySize=true set size of VideoMemorySizeMb internally to size of shared VRAM, which is physical VRAM + RAM used by display driver.

I have 2x GTX-Titan in SLI.

I set the AutodetectVideoMemorySize=FALSE and put the VideoSizeMb=16324 because I have 12GB RAM and 6GB VRAM.

Is that optimal?

[ENBSeries]

SkyrimSuzerain
Read description to ENBoost first, what you did leads to crashes.