kranazoli Posted July 23, 2015 Posted July 23, 2015 Hi, After a long time I'm going to start a new gameplay. I have set enblocal.ini like this: [MEMORY]ExpandSystemMemoryX64=trueReduceSystemMemoryUsage=trueDisableDriverMemoryManager=falseDisablePreloadToVRAM=falseEnableUnsafeMemoryHacks=falseReservedMemorySizeMb=768VideoMemorySizeMb=3968EnableCompression=trueAutodetectVideoMemorySize=false My rig is: ASUS P8P67 Rev 3 | Intel Core i5 2500K | G.Skill Sniper 16GB XMP DDR3 1600Mhz | MSI GTX 980 GAMING 4G | Kingston 96GB V+ SSD | Enermax MODU82+ 625W | Samsung 2333sw FullHD 23"| Windows 7 Prof SP1 x86&x64 | Are those settings right? Or could anyone suggets a better settings?What I want is to avoid CTDs abd ILS and other stuff as far as possible? If this topic is not the right one, please someone sugget me the correct one. Thanks!
Greg Posted July 23, 2015 Posted July 23, 2015 ExpandSystemMemoryX64 should be false and VideoMemorySizeMb seems a bit small for a GTX 980 with 4GB VRAM. This should be set as follows according to the ENBoost page: VideoMemorySizeMb=<integer in MB, multiples of 1024> ;all 32-bit users and 64-bit users with less than 8GB system RAM, set to formula: [Dedicated Video Memory] + [System RAM] − 204 ;64-bit users with ≥ 8GB system RAM, set to formula: [Total Available Graphics Memory] − [170 (for Win7) or 350 (for Win8+)]Notice: To find Dedicated Video Memory and Total Available Graphics Memory in Windows 7 and 8:Right-click the Desktop and click [Adjust screen resolution]. In the middle and right-hand side of the window, click the [Advanced settings] link. In the new window that opens, make sure the [Adapter] tab is the current tab. Under Adapter Information, Dedicated Video Memory and Total Available Graphics Memory are listed.
kranazoli Posted July 25, 2015 Posted July 25, 2015 (edited) Hi, I read about ExpandSystemMomery about in STEP forums and put the question about the latest enb series forum:TES Skyrim 0.279https://enbseries.enbdev.com/forum/viewtopic.php?f=2&t=4476 "And what about these statement?ExpandSystemMemoryX64Warning:It has been reported that this feature can conflict with "Sheson's Memory Patch 3.0" (now included with SKSE) by causing Skyrim to crash if the memory patch fix is used to increase Skyrim's initial heap allocation (Block 1 or DefaultHeapInitialAllocMB in skse.ini) higher than 512MB (or 768MB for some). Therefore, if using the Sheson Memory Patch fix (either standalone or with SKSE), it is recommended to set ExpandSystemMemoryX64 to false.source: STEP EnbGuideThanks!" And got these answers: "ExpandSystemMemoryX64 is very specific thing which do not produce any bugs itself, but the reason of game or mods bugs to appear if they are exist. Kinda same thing happen with 4gb laa patch for oblivion, fallout and old skyrim. There are three levels of same mistake which leads to incompatibility. First one is for 32 bit applications with 2gb memory limit per process, like WinXP and older OS. Second level is 4gb native limit of 32 bit applications and it's the case of ExpandSystemMemoryX64 or 4gb LAA patches. Third is x64 memory ranges and they are not the case of skyrim, because only developers may recompile the same code and bugs will occur, if exists. And the bug itself is when code contains arithmetic operations of memory addresses which may return wrong values if address range is above 2 gb (and 4 gb for x64 version). ExpandSystemMemoryX64 primary goal is to fix memory fragmentation issues which is very problematic thing in almost all games, fragmented memory reduce amount of really available free memory. The best use of this parameter is on vista and higher os. On xp it works too, but have very minor effect." From Boris And something like that: I used ENBoost along with the SKSE Memory Fix and DefaultHeapInitialAllocMB=768 for 100s of hours and I never had any problem. Super stable, no ILS, no CTD. PS: Windows says, my Total VRAM is: 7919Moris VRAM Size Tool says it is: 11904 Which one I use - 170? (I use Win7 x64) Edited July 25, 2015 by kranazoli
Pretendeavor Posted July 25, 2015 Posted July 25, 2015 In case you guys need some more user reports.. I can confirm increased instability (CTDs) with ExpandSystemMemoryX64=true and the SKSE memory patch >= 768. Because of SR:LE+REGS+Dyndolod I use higher values than 768 and keep crashing unless I set it to false.
TechAngel85 Posted July 25, 2015 Posted July 25, 2015 On 7/25/2015 at 3:07 PM, Pretendeavor said: In case you guys need some more user reports.. I can confirm increased instability (CTDs) with ExpandSystemMemoryX64=true and the SKSE memory patch >= 768. Because of SR:LE+REGS+Dyndolod I use higher values than 768 and keep crashing unless I set it to false.Thank you for reporting!
Yippee38 Posted July 27, 2015 Posted July 27, 2015 (edited) The guide says this: Quote Notice: To find Dedicated Video Memory and Total Available Graphics Memory in Windows 7 and 8:Right-click the Desktop and click [Adjust screen resolution]. In the middle and right-hand side of the window, click the [Advanced settings] link. In the new window that opens, make sure the [Adapter] tab is the current tab. Under Adapter Information, Dedicated Video Memory and Total Available Graphics Memory are listed.I think this needs a note because if somebody were to look at their system and see two different numbers for Dedicated Video Memory and Total Available Graphics Memory, they would most likely use the larger of the two numbers. However, if the two numbers are different because they are using SLI (might also be true of Crossfire, but I don't know), they would want to use the lower number. AFAIK, SLI does not make all of the video memory available as one lump sum of memory. Each card uses its own dedicated memory. If people don't know this, they would use the wrong number, and potentially run into problems. Edited July 27, 2015 by Yippee38
FuzzyDuck Posted July 31, 2015 Posted July 31, 2015 Hey, sorry to drop in but...My rig is an AMD Radeon 7870 with 2VRAM and 16 GB of Ram and Windows 7. To the VideoMemorySizeMb setting, what would be the optimal for me to put?I really didn't understand the notes undearneath, i use an 64Bits with Win 7, i've got moar then 8 RAM, so i should use what formula, this one > [Dedicated Video Memory] + [system RAM] − 2048or this one > [Total Available Graphics Memory] − [170 (for Win7) or 350 (for Win8+)]
Greg Posted July 31, 2015 Posted July 31, 2015 If you have 8MB or more RAM with Windows 7 x64, use the second formula: [Total Available Graphics Memory] − 170
FuzzyDuck Posted August 1, 2015 Posted August 1, 2015 Ohh, thx :3 I've..Got really confused with the "≥" symbol XDThx ;3
keithinhanoi Posted August 1, 2015 Posted August 1, 2015 (edited) On 7/25/2015 at 12:05 PM, kranazoli said: Hi, I read about ExpandSystemMomery about in STEP forums and put the question about the latest enb series forum:TES Skyrim 0.279https://enbseries.enbdev.com/forum/viewtopic.php?f=2&t=4476 "And what about these statement? ExpandSystemMemoryX64 Warning:It has been reported that this feature can conflict with "Sheson's Memory Patch 3.0" (now included with SKSE) by causing Skyrim to crash if the memory patch fix is used to increase Skyrim's initial heap allocation (Block 1 or DefaultHeapInitialAllocMB in skse.ini) higher than 512MB (or 768MB for some). Therefore, if using the Sheson Memory Patch fix (either standalone or with SKSE), it is recommended to set ExpandSystemMemoryX64 to false. source: STEP EnbGuide Thanks!" And got these answers: "ExpandSystemMemoryX64 is very specific thing which do not produce any bugs itself, but the reason of game or mods bugs to appear if they are exist. Kinda same thing happen with 4gb laa patch for oblivion, fallout and old skyrim. There are three levels of same mistake which leads to incompatibility. First one is for 32 bit applications with 2gb memory limit per process, like WinXP and older OS. Second level is 4gb native limit of 32 bit applications and it's the case of ExpandSystemMemoryX64 or 4gb LAA patches. Third is x64 memory ranges and they are not the case of skyrim, because only developers may recompile the same code and bugs will occur, if exists. And the bug itself is when code contains arithmetic operations of memory addresses which may return wrong values if address range is above 2 gb (and 4 gb for x64 version). ExpandSystemMemoryX64 primary goal is to fix memory fragmentation issues which is very problematic thing in almost all games, fragmented memory reduce amount of really available free memory. The best use of this parameter is on vista and higher os. On xp it works too, but have very minor effect." From Boris And something like that: I used ENBoost along with the SKSE Memory Fix and DefaultHeapInitialAllocMB=768 for 100s of hours and I never had any problem. Super stable, no ILS, no CTD. Just to clarify here - The "Sheson Memory Patch 3.0" does not change the way TESV.exe (Skyrim's app) allocates memory in its 4GB memory space. Those two "blocks" of heap memory were already programmed by Bethesda to be created when TESV.exe is started. By default, TESV.exe allocates 256MB of memory to both of those blocks. The problem is that when the "Block 1" / Default Heap usage hits 256MB, the routine the programmers used to automatically increase the size of the "Block 1" / Default Heap is flawed, and causes a memory exception error, leading to the instant CTD. This almost always happens as the player is crossing the invisible border of an exterior worldspace cell. Sheson pinpointed the exact two bytes in the TESV.exe binary code which tell the program the default amount memory to allocate to those two blocks of heap memory, and the SKSE team incorporated Sheson's method of writing new values to those two bytes of the program code during SKSE initialization process, before TESV.exe actually starts running. So, this allows the user to manually increase the default "Block 1" / Default Heap allocation, and as a result avoids the problem of the memory exception error, because if you set the default allocation higher than the actual highest memory usage of the "Block 1" heap, then the flawed routine to increase the heap's size never has to be run, and you don't get CTDs for that reason. Sheson also included access to adjust another block of heap memory, called "Block 2", because some people found that when the "Block 1" heap allocation was set to 768MB or higher, then Skyrim would crash upon startup. The workaround for this was to set the initial "Block 2" heap (called the "Scrap Heap" in the SKSE.ini) to 512MB instead of its default 256MB. However, with the great help of Hishtup, I figured out that the "Block 2" scrap heap only needs to be raised to 512MB when ExpandSystemMemoryX64 is set to true. If ExpandSystemMemoryX64 is set to false, then the "Block 1" / Default heap can be set higher than 768MB without the need to set the "Block 2" scrap heap to 512MB. Also very important - in my extensive testing using a program that allows you to track the exact usage of these two blocks of heap memory, I discovered that the "Block 2" scrap heap" never uses more than 256MB, even when you set it to 512MB. However, when its set to 512MB, that extra 256MB of allocated memory is "locked" out, and TESV.exe can't use it for any purpose. The last thing in my testing that I found is that setting ExpandSystemMemoryX64 to true did not significantly increase available free memory in TESV.exe as compared to it being set to false. And it especially doesn't outweigh the loss of 256MB of memory if you have to set the "Block 2" scrap heap to 512MB because you need to set the "Block 1" default heap over 768MB. Again - the benefits of setting ExpandSystemMemoryX64 to true do not outweigh the downside of having to set the "Block 2" scrap heap up to 512MB to avoid Skyrim crashing because "Block 1" is set to 768MB or higher. Because of all of that, the STEP Guide recommends setting ExpandSystemMemoryX64 to false. However, I think the wording of the recommendation is a little unclear because of the way the DefaultHeapInitialAllocMB setting works in SKSE.ini -- Every time I said "over 768MB" for the "Block 1" / Default Heap allocation above, I am talking about the "effective" allocation, which is what TESV.exe actually allocates, as would be seen in either the .log file the SKSE produces or by using Sheson's Memory Block Log SKSE plugin. So, this translates to DefaultHeapInitialAllocMB=1024 in the SKSE.ini file. Remember that the value in the SKSE.ini file must be 256 above the number of MB you want the program to actually use, again which can be verified using Sheson's Memory Block Log SKSE plugin. Therefore, if someone says they are running with DefaultHeapInitialAllocMB=768, and ExpandSystemMemoryX64=true, and have no problems with CTDs or instability, I am NOT surprised at all. The problems can start as soon as you find that you need to set DefaultHeapInitialAllocMB to something over 768 in your SKSE.ini file. For example, with ExpandSystemMemoryX64 set to true, and I set DefaultHeapInitialAllocMB to 800 (which equates to an "effective" allocation of 544MB), Skyrim will crash upon startup, unless I set ScrapHeapSizeMB=512 ("Block 2"), and you now know by doing this, it means I am wasting 256MB of memory. So I would want to set ExpandSystemMemoryX64=false in enblocal.ini, and set ScrapHeapSizeMB=256 in SKSE.ini, and I'm not wasting 256MB of memory and Skyrim doesn't crash. Boris is right to say that the code he uses to change memory allocation when ExpandSystemMemoryX64 is set to true does not cause bug on its own, but rather what is happen is some kind of interaction between TESV.exe allocation of the two heap memory blocks and his routine under certain circumstances. The STEP recommendations here are not something pulled out of the dark randomly. Quite a lot of time has been spent and investigation into the reasons for the CTDs, and my explanation above has been confirmed by enough people by now that it's consistent and repeatable. If in doubt, I recommend you try some tests yourself - in the name of science! Edited August 1, 2015 by keithinhanoi 2
oqhansoloqo Posted August 1, 2015 Posted August 1, 2015 On 8/1/2015 at 7:54 AM, keithinhanoi said: However, with the great help of Hishtup, I figured out that the "Block 2" scrap heap only needs to be raised to 512MB when ExpandSystemMemoryX64 is set to true. If ExpandSystemMemoryX64 is set to false, then the "Block 1" / Default heap can be set higher than 768MB without the need to set the "Block 2" scrap heap to 512MB. Again - the benefits of setting ExpandSystemMemoryX64 to true do not outweigh the downside of having to set the "Block 2" scrap heap up to 512MB to avoid Skyrim crashing because "Block 1" is set to 768MB or higher. While I admire your extensive knowledge about a lot of Skyrim-related technical issues, my system is not suffering from these memory constraints that you brought up as being issues when using ExpandSystemMemoryX64 set to true. My SKSE.ini settings:[Memory]DefaultHeapInitialAllocMB=768ScrapHeapSizeMB=256 In enblocal.ini I have ExpandSystemMemoryX64 set to true. I rarely ever suffer from CTDs. According to what you just said, if I set that enblocal.ini setting to true then I would have to set block 2 to 512. I didn't have to do this. I also don't get CTDs from having block 1 set to 768.
TechAngel85 Posted August 1, 2015 Posted August 1, 2015 On 8/1/2015 at 7:54 AM, keithinhanoi said: Because of all of that, the STEP Guide recommends setting ExpandSystemMemoryX64 to false. However, I think the wording of the recommendation is a little unclear because of the way the DefaultHeapInitialAllocMB setting works in SKSE.ini --If you can think of any why to clarify the recommendation, please do so: https://wiki.step-project.com/Guide:ENBlocal_INI/Memory#ExpandSystemMemoryX64 I've never been a fan of Z's technical warning as most would not be able to understand it. I just added a link to your post above though.
keithinhanoi Posted August 1, 2015 Posted August 1, 2015 (edited) On 8/1/2015 at 12:56 PM, oqhansoloqo said: While I admire your extensive knowledge about a lot of Skyrim-related technical issues, my system is not suffering from these memory constraints that you brought up as being issues when using ExpandSystemMemoryX64 set to true. My SKSE.ini settings:[Memory]DefaultHeapInitialAllocMB=768ScrapHeapSizeMB=256 In enblocal.ini I have ExpandSystemMemoryX64 set to true. I rarely ever suffer from CTDs. According to what you just said, if I set that enblocal.ini setting to true then I would have to set block 2 to 512. I didn't have to do this. I also don't get CTDs from having block 1 set to 768. I'm sorry that it's such a long post, but it really has to be read to the end: On 8/1/2015 at 7:54 AM, keithinhanoi said: Every time I said "over 768MB" for the "Block 1" / Default Heap allocation above, I am talking about the "effective" allocation, which is what TESV.exe actually allocates, as would be seen in either the .log file the SKSE produces or by using Sheson's Memory Block Log SKSE plugin. So, this translates to DefaultHeapInitialAllocMB=1024 in the SKSE.ini file. Remember that the value in the SKSE.ini file must be 256 above the number of MB you want the program to actually use, again which can be verified using Sheson's Memory Block Log SKSE plugin. Therefore, if someone says they are running with DefaultHeapInitialAllocMB=768, and ExpandSystemMemoryX64=true, and have no problems with CTDs or instability, I am NOT surprised at all. The problems can start as soon as you find that you need to set DefaultHeapInitialAllocMB to something over 768 in your SKSE.ini file. For example, with ExpandSystemMemoryX64 set to true, and I set DefaultHeapInitialAllocMB to 800 (which equates to an "effective" allocation of 544MB), Skyrim will crash upon startup, unless I set ScrapHeapSizeMB=512 ("Block 2"), and you now know by doing this, it means I am wasting 256MB of memory. So I would want to set ExpandSystemMemoryX64=false in enblocal.ini, and set ScrapHeapSizeMB=256 in SKSE.ini, and I'm not wasting 256MB of memory and Skyrim doesn't crash. So, with your settings, I would expect no CTDs. Keeping ScrapHeapSizeMB=256 and ExpandSystemMemoryX64=true, if you increase your DefaultHeapInitialAllocMB to 1024 ("effective" 768MB in-game), there's a good chance you will see Skyrim crash as I and other have. If no crash, try going higher, all the way up to the maximum - DefaultHeapInitialAllocMB=1280 ("effective" 1024MB in-game), and it's almost guaranteed that Skyrim will crash. When you've found a value for DefaultHeapInitialAllocMB that causes Skyrim to crash, then set ScrapHeapSizeMB=512, and Skyrim should start and work fine (I was running like this for quite some time, actually). After that, set ScrapHeapSizeMB back to 256, and set ExpandSystemMemoryX64=false. Skyrim should also work fine, but it's just gained 256MB in its memory space to make use of. Here's something of a chart to make it clearer: ExpandSystemMemoryX64=trueDefaultHeapInitialAllocMB=768ScrapHeapSizeMB=256Result --> No CTD / Stable ExpandSystemMemoryX64=trueDefaultHeapInitialAllocMB=1024 (or even > 768)ScrapHeapSizeMB=256Result --> CTD on startup for some users ExpandSystemMemoryX64=trueDefaultHeapInitialAllocMB=1280 (or even > 1024)ScrapHeapSizeMB=256Result --> CTD for most everyone ExpandSystemMemoryX64=trueDefaultHeapInitialAllocMB=769 or higherScrapHeapSizeMB=512Result --> No CTD on startup / Mostly stable but 256MB of memory wasted ExpandSystemMemoryX64=falseDefaultHeapInitialAllocMB=769 or higherScrapHeapSizeMB=256Result --> No CTD / Stable and you didn't waste 256MB of memory I hope that helps explain it better. I really really wish SKSE hadn't decided to make it so the DefaultHeapInitialAllocMB value has to be 256 higher than what you want in-game. It leads to so much confusion... If you try these tests and have different results, by all means - please let us know. It's really important to know if there are some exceptions to this. Edited August 1, 2015 by keithinhanoi
oqhansoloqo Posted August 1, 2015 Posted August 1, 2015 On 8/1/2015 at 1:59 PM, keithinhanoi said: I hope that helps explain it better. That was really good. Thank you - the examples help a lot. So why would someone want to set block 1 higher than this example?: ExpandSystemMemoryX64=trueDefaultHeapInitialAllocMB=768ScrapHeapSizeMB=256 What benefit could I gain by doing this instead?: ExpandSystemMemoryX64=falseDefaultHeapInitialAllocMB=769 or higherScrapHeapSizeMB=256 In other words - Is it better to have the expanded X64 system memory or have more MB (greater than 768) in block 1? If it's not better to have more than 768, does the game run worse or better with the use of expanded X64 system memory (set to true)? My hunch would be that it's better.
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now