ENBoost/Skyrim INIs recommended STEP settings wrong?

[blattgeist]

Hi STEP community. This is my first post here so I hope this is the right place.

 

I noticed that the description for recommended ENBoost settings might be wrong on a certain part:

 

Quote: "Set this line to true to use the memory reduction features without the graphic modifications of ENB.

UseDefferedRendering=(false, true)" http://wiki.step-project.com/ENBoost

I believe the line above is wrong. Setting it to true would be for ENB - users and settings it to false for Non - ENB users, meaning for people that do not use any graphical modifications.

 

 

Evidence? This post:

 

from Skyliner90 in the ENBoost comments on Nexus, Quote:

 

"UseDefferedRendering=true Some sort of rendering technique, unimportant unless you use ENB graphics."

 

And also this post: https://forums.nexusmods.com/index.php?/topic/1042116-ctd-and-performance-patch-enboost/page-70

 

Quote: "Most if not all ENB presets work with ENBoost. Pick an ENB you like, use v0193 or latest enb, change UsePatchSpeedhackWithoutGraphics=false and UseDefferedRendering=true in enblocal.ini for enb effects. If your enb comes with sweetfx, change EnableProxyLibrary=true, InitProxyFunctions=true and ProxyLibrary=yoursweetfx.dll in enblocal.ini as well."

 

 

So... am I right?

 

Greetings, blattgeist.

 

 

Edit: Here the link to the STEP site that I was referring to.

 

https://wiki.step-project.com/Recommended_ENB_Profiles#Global

Edited May 6, 2014 by EssArrBee

[blattgeist]

Getting back to this after a while.

 

@Keithinhanoi,

 

you said "Setting EnableCompression to true will reduce actual VRAM usage" but STEP says "This setting will allow for more compression in system RAM by having more textures moved into VRAM. It is not recommenced to be set "true" if already near VRAM limit and be "false" if there is VRAM to spare."

 

I am kind of puzzled by that. If I follow STEP's statement then it increases vram usage when set to true... and if I follow yours then it decreases vram usage.. hm... Don't you maybe mean that if I set compression to true it reduces RAM usage by moving RAM into VRAM?

 

 

Can you enlighten me please?^^

 

 

edit: Another source says this : "if you have not more as 2 gb vram, set it to true but you loss a little bit of quality. with compression enable you can load more textures in your vram as your card have." https://forums.nexusmods.com/index.php?/topic/905060-realvision-enb/page-1501

 

 

The general opinion seems to be that if you enable compression it gives a slight fps boost by using less total memory (i guess that's RAM) boost but can cause micro stutters. I really wish information for this setting would not be so scattered all across the forums.

 

Edit2: To be honest the step recommendation regarding compression is contradicting itself..

Quote: "It is not recommenced to be set "true" if already near VRAM limit and be "false" if there is VRAM to spare."

 

--> Now if I convert that sentence to positives it says: "It is recommended to be set to false if already near VRAM limit and be "false" if there is VRAM to spare." You get what I mean right?

 

 

 

Edit3: Much digging into the ENB Nexus Forum: https://forums.nexusmods.com/index.php?/topic/905060-realvision-enb/page-2257&do=findComment&comment=11793980

 

Here are my results, I only quote (but without names, just read from the posted Link and then below):

 

"i recommend all: set EnableCompression to true. great performance boost. the card can handle now over 190 GB/sek. readme of enbseries: Changed ENBoost, now it support up to 128 Gb of memory or about 192 when compression enabled".

 

--> "But the compression its been said that gives more stutter than non compress?? What has been change for that? "

 

--> "no, no stutters, better performance. enboost can handle now the higher bandwidth of the card. "

Edited April 16, 2014 by blattgeist

[keithinhanoi]

blattgeist, that explanation was bad, and not based on my usual in-depth level of research. I've got no excuse for forgetting to put my normal disclaimer of "as I understand it..." So, I apologize for the confusion.
 
I've just scoured the ENB Forums, and unfortunately this is one of those settings where a simple search for certain text will reveal the whole picture.
 
Here's what I did find, though, mostly searching for direct quotes from Boris:

 

Boris, 8 Aug 2013:
"New version of memory reducing almost finished. Made compression (used fastest existing algorithm, but with official hi-res textures loading takes 3 seconds longer) to decrease memory usage even on x86 systems without enbhost.exe. And did dynamic unloading to fix freezing, low fps and black textures, but not yet tweaked properly yet, it may take a lot of time to get statistics, so don't expect this feature will start to work from first day."

Boris, 9 Aug 2013:
"I don't know what microstutters everyone talking about, this code work exactly the same as previous if cells not loading. Also memory compression performance on my old cpu is about 400 mb per second and decompression 1.5 gb per second, you can't notice such difference, except at loading saved game (and definetly i don't care if it longer). The main goal of testing if enbhost don't have problems with antiviruses and other ****ed up systems is lost somewhere behind garbage, nice."

Boris, 9 Aug 2013:
"KuroTenshi
On your pc 0.5 sec means that about 300 mb of textures and geometry compressed. I don't believe that game cell loading from files and creation of objects takes less time than my compression, even if you running game from ssd. From my tests uncompressed in older 0.200 took 0.4 sec to load data in to enbhost or in to skyrim process, including cost of memory allocation functions, compressed 3 seconds for that. Of course it's time of loading saved game with official hi-res texture pack installed, without it 1/10 of that, measuring individual cell loading time impossible. I can try to compress in different thread, but don't think this will help much."

Boris, 11 Aug 2013:
"I just found that compression i did cost a lot of performance when memory for textures not enough while looking at some objects and heavy stuttering occur. Will try to prebuffer them uncompressed, let's say about 100 mb buffer to keep them. Compression itself is very helpful when enbhost.exe not running or 32-bit OS."

Boris, 17 Aug 2013:
"Graphic mod / patch ENBSeries 0.204

This version have same code of memory manager as test version 4 of 0.202 (by response of testers), but main difference is in multithread locking operations, reworked them to exclude deadocks (which produced freezes with timeout in 0.202), but for performance reasons restored partially multithreading without blocking for textures which loading. For me stutter occur when cells loading, but it's because of compression (to decrease memory cost in 1.5 times) and double work to fix game bug with textures when their quality in video options set to not "high", guess later i can fix that by adding another thread for such computations. Waiting of test results to understand where to move next."

Boris, 20 Aug 2013:
"Phinix
I already disabled bugfix for textures at maximal quality and if you don't like this, don't expect any changes from me, because it's compression and i will not turn it off as it give 1.5 times more ram and it's the fastest algorithm in the world (lz4)."

Boris, 24 Aug 2013:
"EnableUnsafeMemoryHacks=false - yes, again. This is for videocards with a lot of video memory, because this mode is if player don't want to have any stuttering, any side effects (except alt+tab issue) or by some reason this set to false not work (reason actually other software). This mode also perfect if user have disbalanced system like 32 bit OS and videocard with 4 gb video memory. This mode don't use dynamic memory reallocation, so no compression, no enbhost.exe. Also it work only when ReduceSystemMemoryUsage=true set."

Boris, 11 Sep 2013:
"CruNcher
My compression is only 1.5 ratio and affect data in ram only. If textures uncompressed, then they longer loading (stuttering on cells transitions) and use more video memory.
DXT compression is good thing in graphics, but everything depends from compressor, good quality only can be achieved by complex algorithms when same image compressed many times and then compared to initial data to choose better one. NVidia DDS plugin for photoshop work slow, but i mean even slower, for some images processing require minutes to find the best result. Nobody care from modders about such things, so for sure they use any available method."

Original post from Cruncher, 11 Sep 2013
"it can it depends on the compression encoding/decoding time vs the bandwith ratio i would say though MipMaps save the most performance as you don't continuously have to rescale the texture based on it's lod, boris ENB though uses a very good realtime lossless compression that lowers bandwith and is really fast "

Boris, 29 Sep 2013:
"Graphic mod ENBSeries / patch ENBoost 0.223

Added parameter to disable compression of memory manager to reduce stuttering while objects are loading at cost of memory usage. Removed [CAMERAFX] category from enbseries.ini, added [LENS] category and separate enblens.fx shader with enblensmask image. Removed lens reflection code from enbbloom.fx. Added FieldOfView variable to shaders."

Boris, 29 Sep 2013:
"enbhost.exe memory usage increased and process memory used only when enbhost.exe return out of memory, so you measured wrong thing. Compression reduce memory usage 1.5 times."

Jafin16, 1 Oct 2013:
"With EnableCompression=false I didn't do any specific tests to see how high my memory went but rather decided to see how it played ('cuz I'm fairly sure your average user isn't going to be looking at their Ram usage the entire time they play) and all I noticed was smoother gameplay. No stutters, slightly better framerate (1-5 frames depending on the scene). I may do some more specific tests today if I get the time."

Boris, 1 Feb 2014:
"Graphic mod ENBSeries / patch ENBoost 0.250

Changed ENBoost, now it support up to 128 Gb of memory or about 192 when compression enabled, may be this will be useful for the future. Don't forget to update ENBHOST.EXE file."

 
Now, from all of that - as I understand it -
 
Boris added the compression feature, without any option to disable it, in v0.200 in an effort to reduce system RAM usage of cached data.
 
It uses LZ4 compression for 1.5:1 ratio improvement for storage of cached texture and object data. So in other words, 150MB of cached data will take up 100MB of RAM.
 
Initially Boris talks about it being especially useful for people running on 32-bit Windows, or if enbhost.exe is not used. From this, I deduce that the compression of cached data stored in RAM is applied to memory allocated by ENBoost in Skyrim itself (TESV.exe).
 
Much later, with ENB v0.250, he extended the memory limit of ENBoost to 128GB, "or about 192 when compression enabled." This means that the compression is also applied to cached data stored in the RAM allocated by instances of enbhost.exe. When I say "instances" this means that there can be more than one enbhost.exe running on your system. When the first instance of enbhost.exe is full with 4GB of data, another one will be started.
 
Nowhere did I find Boris saying that the ENBoost compression added in v0.200 is applied to any data stored in the VRAM of your videocard.
 
Also, as far as I can tell, the compression is applied in addition to whatever compression was used to make the textures themselves. So, if a particular texture file was created with DXTx compression, that gets read from your HDD/SDD, compressed using LZ4 and cached to RAM allocated by ENBoost in either TESV.exe or enbhost.exe. When that cached data is read to be used for rendering, it is decompressed and written to VRAM, in it's "original" form (ie., with DXTx compression).
 
Adding to this, Boris reiterates something that I've read in plenty of places and makes a lot of sense - if you are using uncompressed textures, they take longer to load in cell transitions, and also take up more VRAM on your videocard.
 
So, based on all of this, the compression feature should have no effect on VRAM usage - and this of course conflicts with a lot of reports and information I've read elsewhere (and not from Boris directly.) What will still have an effect on your VRAM usage is the size (resolution and compression) of the texture files being used in your game.
 
After Boris introduced the compression feature, quite a few people reported that although they saw their system RAM usage decreased, the were experiencing stuttering / micro-stuttering. Finally, despite at first saying he would not change the feature, he added the EnableCompression= .ini toggle setting in ENB v0.233.
 
I have not had a chance to read all users' reports on the enablecompression setting after it was added, but from what I did see, there are both people who experience stuttering with it enabled and others who get more stuttering with it disabled.
 
Other important things to note are:

• [*]Boris' ENBoost compression feature is completely disabled when EnableUnsafeMemoryHacks=true [*]It

appears that, if enabled, compression will still be used even if enbhost.exe is disabled with the setting ReduceSystemMemoryUsage=false.

So, with your 16GB, I'd imagine saving on system RAM is not so much of a concern, so the advice here should be to try enabling / disabling compression to see which setting results in less stuttering / smoother gameplay.
 
I've also edited my post with the erroneous explanation - again, a big apology for that!

Edited April 16, 2014 by keithinhanoi

[Kuldebar]

From my experience on my system, I'm more prone to have black textures (usually on player character face) when compression is disabled but I haven't tried turning off compression since going to a much lighter texture build. (I use HD Vanilla + Parallax for Landscape now)

[keithinhanoi]

I just did a bit more digging on the sources of my previous understanding that enabling compression in ENBoost will reduce VRAM usage.

 

Probably the most trustworthy source of that idea was from Phinix, who has added explanations right into the enblocal.ini that he supplied with his Phinix Natural ENB. It's just been updated to v2.0, and when I downloaded it and checked in the enblocal.ini that it comes with, sure enough, this is what I found:

 

//Disabling may reduce stuttering in some cases, however can also

//cause significantly higher VRAM use.

EnableCompression=true

 

So, I hope that helps to explain where I've gotten that idea from. Perhaps asking Boris himself would be the best way to make sure?

Edited April 16, 2014 by keithinhanoi

[Kuldebar]

Yeah, I tried it out after my last post in this thread...my VRAM went up by 200+ on average in Falkreath (ETAC). I have GPU info displayed on my G13 Gaming Pad while I play using AIDA64 Extreme Edition report monitor. I have two GPU Memory Readings, one is usually hovering slightly under my physical GPU chip based VRAM (1024) and the other is usually under 450MB..without compression the second entry was 650+MB:

 

 

[z929669]

Getting back to this after a while.

 

@Keithinhanoi,

 

you said "Setting EnableCompression to true will reduce actual VRAM usage" but STEP says "This setting will allow for more compression in system RAM by having more textures moved into VRAM. It is not recommenced to be set "true" if already near VRAM limit and be "false" if there is VRAM to spare."

This is about as clear as mud, and I disclaim any responsibility for that wording. I am certain that it is semantically inaccurate and misleading.

 

Unfortunately, there is a lot of info on our wiki that could use revision and clarity. Better to simply state that setting to 'true' will minimize use of VRAM for those that need it, but it will come at the cost of processing time to render graphics, leading to stuttering at times.

 

I in fact do not know this to be true or not, but I have plenty of VRAM and sys RAM for ENBoost to work with. Needs testing to confirm, but that is the gist I think.

[blattgeist]

Oh wow good to see some life in this thread :)

 

I thank you for all the details Keithinhanoi and there is no need to apologize. We're all trying to help each other with this info.

 

This statement is kinda interesting:

 

Jafin16, 1 Oct 2013:
"With EnableCompression=false I didn't do any specific tests to see how high my memory went but rather decided to see how it played ('cuz I'm fairly sure your average user isn't going to be looking at their Ram usage the entire time they play) and all I noticed was smoother gameplay. No stutters, slightly better framerate (1-5 frames depending on the scene). I may do some more specific tests today if I get the time."

 

He should experience a better framerate with comprression enabled...

 

 

 

I have found an interesting link for those of you who are interested, it comes from the ENB Nexus Forum:

 

https://www.workupload.com/download/9W9HQ23O

 

 

In there is a txt that gives brief explanations about what the different commands do and what the recommended setting is.

From what I understand regarding compression is that people seem to experience less vram usage although as you stated it should not be less at all. So I will activate it for now and see if I get stutters.. But unfortunately I can not extensively test that at the moment because I am still in the process of documenting MCM menu settings for my mod, which takes a lot of time.

 

I will report back about my findings after I'm done with that though.

 

By the way is there any possibility to make enboost auto clean the cache? (F4 Key) instead of pushing the button every now and then? I also search for a tool that can display vram/ram usage ingame.. I used to run elys meminfo but I believe that is not supported by enboost/ssme?

 

@Ixian Inventor

The majority of the info on STEP is fine though. But you guys need more people. STEP looks like a fulltime job ^^

Edited April 16, 2014 by blattgeist

[z929669]

Unfortunately, much of what Boris says is not qualified or presented out of context. I find most of his posts confusing ...
 

... snip/

Boris, 11 Aug 2013:
"I just found that compression i did cost a lot of performance when memory for textures not enough while looking at some objects and heavy stuttering occur. Will try to prebuffer them uncompressed, let's say about 100 mb buffer to keep them. Compression itself is very helpful when enbhost.exe not running or 32-bit OS."

I translate this to mean that when textures required for situational cell-loading exceed VRAM capacity (or when all needed info is not in VRAM at the given moment of the need), then sys RAM info is needed, and that has the additional lz4 compression overhead. This all corroborates the idea that the lz4 compression is distinct from texture compression, and ENB's lz4 compression is applied to information contained within TESV and ehbhost processes; however, some proportion of info contained within TESV (and possibly enbhost) process is also contained within VRAM, so I am supposing that 1z4 compression may not be restricted only to sys RAM (but that may be where it lives predominantly).
 

... snip/

Boris, 24 Aug 2013:
"EnableUnsafeMemoryHacks=false - yes, again. This is for videocards with a lot of video memory, because this mode is if player don't want to have any stuttering, any side effects (except alt+tab issue) or by some reason this set to false not work (reason actually other software). This mode also perfect if user have disbalanced system like 32 bit OS and videocard with 4 gb video memory. This mode don't use dynamic memory reallocation, so no compression, no enbhost.exe. Also it work only when ReduceSystemMemoryUsage=true set."

This is very confusing. It seems like he is answering a question, so it is unclear if it was "should I ... ?" or "should I not ... ?". What do the various references to 'this' and 'this mode' refer to?? EnableUnsafeMemoryHacks=true/false ... something more not in this post ... ?? Very unclear to me.
 

... snip/

Boris, 29 Sep 2013:
"Graphic mod ENBSeries / patch ENBoost 0.223

Added parameter to disable compression of memory manager to reduce stuttering while objects are loading at cost of memory usage. Removed [CAMERAFX] category from enbseries.ini, added [LENS] category and separate enblens.fx shader with enblensmask image. Removed lens reflection code from enbbloom.fx. Added FieldOfView variable to shaders."

Again, loading from where exactly?? VRAM or sys RAM or both? Knowing source is very important to gleaning the EnableComression theoretical effects.
 

... snip/

Boris, 29 Sep 2013:
"enbhost.exe memory usage increased and process memory used only when enbhost.exe return out of memory, so you measured wrong thing. Compression reduce memory usage 1.5 times."

So this seems to be saying that lz4 compression is predominant in enbhost process and secondary in TESV process? What about additional enbhost process(s)? Very unclear to me.
 

... snip/

Jafin16, 1 Oct 2013:
"With EnableCompression=false I didn't do any specific tests to see how high my memory went but rather decided to see how it played ('cuz I'm fairly sure your average user isn't going to be looking at their Ram usage the entire time they play) and all I noticed was smoother gameplay. No stutters, slightly better framerate (1-5 frames depending on the scene). I may do some more specific tests today if I get the time."

This kind of interpretation could be placebo. Need actual data.
 

... snip/
 
Now, from all of that - as I understand it -
 
Boris added the compression feature, without any option to disable it, in v0.200 in an effort to reduce system RAM usage of cached data.
 
It uses LZ4 compression for 1.5:1 ratio improvement for storage of cached texture and object data. So in other words, 150MB of cached data will take up 100MB of RAM.
 
Initially Boris talks about it being especially useful for people running on 32-bit Windows, or if enbhost.exe is not used. From this, I deduce that the compression of cached data stored in RAM is applied to memory allocated by ENBoost in Skyrim itself (TESV.exe).

Possibly, but that would imply that VRAM can contain the lz4 compressed info too (if it is true that video memory from TESV process is redirected preferentially into VRAM and enbhost process secondarily.)
 

Much later, with ENB v0.250, he extended the memory limit of ENBoost to 128GB, "or about 192 when compression enabled." This means that the compression is also applied to cached data stored in the RAM allocated by instances of enbhost.exe. When I say "instances" this means that there can be more than one enbhost.exe running on your system. When the first instance of enbhost.exe is full with 4GB of data, another one will be started.
 
Nowhere did I find Boris saying that the ENBoost compression added in v0.200 is applied to any data stored in the VRAM of your videocard.

But I suspect it is (see previous comments).

 

Lots of good progress though. Just a few kinks that still bother me (I want to correct the info in the ENB guide).

[Aiyen]

This is how I see it. 

 

Having stuff compressed means it take up less space... in this case less memory per texture loaded. 

The bad side of this is that it takes longer to load every texture then... requires more bandwidth per texture to load. 

 

So if you have compression on, then you take up less space in terms of memory, but you might suffer stuttering due to a bottle neck in getting the data loaded. 

 

So there are only really two scenarios one need to consider when debating if you should have it on or off. 

 

A: You are running near your memory limits hence stuttering due to this is a huge issue. Enabling compression will give you a bit more playing room and you will reduce stuttering since bandwidth is the lesser bottleneck. 

 

B: You got all the memory in the world, but you are simply using too many high res textures, at 60 FPS while running around spinning like a mad person. Here you would disable compression to get a bit more bandwidth to support your crazy movements.. since the main bottleneck is the bandwidth to read all the data. 

 

 

Ofc. you can also get examples where both apply.... since it is still a dx9 app. then there are upper limits on VRAM allowable etc. This is still why even with ENBoost and 6Gb of VRAM you cannot run at full 4k textures everywhere. With even a moderate amount of 4k textures you simply run into a mix of not enough memory and no where near enough bandwidth to move the data amounts around fast enough.  

[Kuldebar]

This is how I see it. 

 

Having stuff compressed means it take up less space... in this case less memory per texture loaded. 

The bad side of this is that it takes longer to load every texture then... requires more bandwidth per texture to load. 

 

So if you have compression on, then you take up less space in terms of memory, but you might suffer stuttering due to a bottle neck in getting the data loaded. 

 

So there are only really two scenarios one need to consider when debating if you should have it on or off. 

 

A: You are running near your memory limits hence stuttering due to this is a huge issue. Enabling compression will give you a bit more playing room and you will reduce stuttering since bandwidth is the lesser bottleneck. 

 

B: You got all the memory in the world, but you are simply using too many high res textures, at 60 FPS while running around spinning like a mad person. Here you would disable compression to get a bit more bandwidth to support your crazy movements.. since the main bottleneck is the bandwidth to read all the data. 

 

 

Ofc. you can also get examples where both apply.... since it is still a dx9 app. then there are upper limits on VRAM allowable etc. This is still why even with ENBoost and 6Gb of VRAM you cannot run at full 4k textures everywhere. With even a moderate amount of 4k textures you simply run into a mix of not enough memory and no where near enough bandwidth to move the data amounts around fast enough.  

 

So, best answer regarding compression: it depends.

 

I think I will run a lengthy more varied session without compression enabled so I can better gauge things like the occurrence of stuttering, freezes, choppiness along with general FPS rates.

[blattgeist]

Yeah that's how I see it too.. if you get stutters.. disable it. Though I get ctds from time to time.. randomly. But that might not be related to anything in here. Simply switching out of menus and into combat too fast maybe.

 

Like when I walked into bleak falls barrow with a firespell, burning down enemies, quickly switched into the menu and out again and bam ctd lol... But that could be anything.

Edited April 16, 2014 by blattgeist

[Kuldebar]

I had my first CTD in like forevah with compression disabled...inside the Temple in Whiterun of all places when I panned my character around inside while the Priestess was talking to the Pilgrim.

 

There's still plenty I could test, but, TBH, my game seems to run fine if not better with compression enabled but I can't back that up "scientifically". 

 

I suspect ReservedMemorySizeMb would probably need to be adjusted according to the texture load and the system and whether compression is used. I can't see how there wouldn't be some interaction between reserved memory settings and compression activity. The ReservedMemorySizeMb is now my flavor of the month setting it seems, I just upped it after my compression experiment CTD to 896MB from the 512MB previously.

blattgeist, on 16 Apr 2014 - 1:48 PM, said:

Like when I walked into bleak falls barrow with a firespell, burning down enemies, quickly switched into the menu and out again and bam ctd lol... But that could be anything.

That reminds me of the SkyUI/SafetyLoad CTD's I used to get before the days of SSME/Sheson.

Edited April 16, 2014 by Kuldebar

[blattgeist]

I use SSME and SKSE 1.6 so.. that should prevent CTDs. Not enough tests done yet to be sure what causes what. My reservedmemorysize is at 256 by the way. I read somewhere that it is recommended for 4GB cards. I will switch to the newer skse version soon, but will disable the memory patch feature until it is out of alpha.

 

Could a CTD be caused by a player not finishing the helgen quest and then going somewhere else, doing random stuff? Because I did just that for testing purposes. Some kind of bad loop maybe :)

 

Sorry for being offtopic ^^

Edited April 17, 2014 by blattgeist

[Kuldebar]

blattgeist, on 16 Apr 2014 - 5:28 PM, said:blattgeist, on 16 Apr 2014 - 5:28 PM, said:blattgeist, on 16 Apr 2014 - 5:28 PM, said:blattgeist, on 16 Apr 2014 - 5:28 PM, said:blattgeist, on 16 Apr 2014 - 5:28 PM, said:blattgeist, on 16 Apr 2014 - 5:28 PM, said:

I use SSME and SKSE 1.6 so.. that should prevent CTDs. Not enough tests done yet to be sure what causes what. My reservedmemorysize is at 256 by the way. I read somewhere that it is recommended for 4GB cards. I will switch to the newer skse version soon, but will disable the memory patch feature until it is out of alpha.

 

Could a CTD be caused by a player not finishing the helgen quest and then going somewhere else, doing random stuff? Because I did just that for testing purposes. Some kind of bad loop maybe :)

 

Sorry for being offtopic ^^

I can only speak for my own experience on my system (specs below) but sudden CTD's that happen after a fast cell load or opening up a large inventory when a lot of other things (new cell, number of NPC's, effects etc.) are going on, are what I attribute to having the ReservedMemorySizeMb set too low on my system.

 

Every time I took some advice on lowering the value or simply decided to experiment with numbers lower than 512...the more instances of such CTD's I would have. Basically, the smaller the ReservedMemorySizeMb size the more prone I am to have CTD's of the nature I described. (My CTD to hours played is really good btw...the period between them can be measured in days if not weeks)

 

I find this odd, but my slow, plodding evolution of awareness has led me to always keep ReservedMemorySizeMb over 512MB.

 

Boris stated:

 

QuoteQuoteQuoteQuoteQuoteQuote

ReservedMemorySizeMb - this depends too much from 32/64 bit system and vram size. Smaller - less ram usage of the game (fewer CTDs), but bigger in most cases means less stuttering in very heavy areas where many mods used (and ugrid too high). If user have 512 mb of vram, this value 512 is also nice, because entire video memory will be dynamic, it's already small for heavily modded game, so better to not block it by static data. As i understood from posts, lower value also helps to some users with infinite loading screens (perhaps they happen because i'm forcing in cycle to free old memory and try again to allocate for new resources).

 

Smaller reserved memory size "less ram usage of the game (fewer CTDs)" ...which is pretty much the opposite of my experience on my system but what I originally had taken as the gospel by running with 64, 128 or 256 sizes. Then in his next sentence...Boris drops a counter bomb by stating that higher values might have positive returns. So, in my opinion, there's quite a bit of latitude for figuring out what's best for your system.

 

You may have plenty of VRAM, but the ENB has to juggle stuff around, maybe ReservedMemorySizeMb isn't something to just leave sit at 256...especially when you have those sudden desktop visits and other causes have been ruled out. (Your delaying the main quest/CTD theory doesn't sound plausible. :p )

 

 

UPDATE on my "testing" with compression set to false

 

Well, my game is more responsive with less delays when doing certain actions like the KeyFreeVRAM and less sluggish turns on character, the camera moves more freely. Distance LOD handling appears improved. FPS doesn't appear to have been impacted plus or minus, other than the general responsiveness which is improved but hard to measure.

 

VRAM usage is up, but not alarmingly so...I had no CTD's but I also upped my ReservedMemorySizeMb, here's my settings:

 

[MEMORY]

ExpandSystemMemoryX64=true

ReduceSystemMemoryUsage=true

DisableDriverMemoryManager=false

DisablePreloadToVRAM=false

EnableUnsafeMemoryHacks=false

ReservedMemorySizeMb=896

VideoMemorySizeMb=0

EnableCompression=false

AutodetectVideoMemorySize=true

 

* changed settings

 

So, I am going to play with the changed settings for while, so far I have no reason to revert back to compression.

 

UPDATE #2

 

Still going strong, another plus with compression turned off is loading into a cell there's not that usual freeze I used get as my character rendered into the environment. Exiting Shroud Hearth Barrow, for example... I'd usually have a brief sluggish moment after leaving the dungeon, not so anymore.

Edited April 17, 2014 by Kuldebar

[keithinhanoi]

Kuldebar - I'm curious as to what the ENB GUI reports your Video Memory to be, now that you're trying out AutodetectVideoMemorySize=true.
 
Also, I've just posted on the ENB thread for 0.252 to ask Boris definitively about the limits of VideoMemorySizeMb. Jafin16 visted another thread here on STEP, and said that the max limit is 10240 (10Gb,) despite my ENB GUI reporting between 15-17Gb when I set AutodetectVideoMemorySize=true.
 
Boris has actually answered the question before, saying the limit is 1 Terabyte (!!!!), and interestingly nobody even batted an eyelash on that reply.
 
Well, his reply to me came damn quick, and what do you know - the limit for VideoMemorySizeMb really is 1 Tb, but based his answer, seeing a large value for Video Memory in the ENB GUI is not a good thing.
 
So that still leaves the question of what is a good value for VideoMemorySizeMb, and although there is still a very large camp of people stating that the formula ((RAM + VRAM) - 2048) works best, when Boris was asked about it, this is how he replied:
 

"That formula is not correct, but it's fit to most players who have 8 gb of ram and it doesn't matter when 16 gb (as it's too much). Perfect value can be found with other software, don't remember how it's named for casuals, "shared video memory" i guess. Anyway real video memory give best performance, but available video memory is bigger than physical always."

 

I think what he's referring to when he talks about the "other software" and "shared video memory" is DXDiag, which on my system reports shared video memory as being 4GB (4095MB to be exact) even though I've got 1GB of VRAM. So that follows his explanation of "available video memory is bigger than physical always" as Windows extends video memory by sharing system RAM with the video driver.
 
In practical terms, however, even though he states the obvious that real video memory gives the best performance, implying that setting VideoMemorySizeMb to the equivalent of the amount of physical VRAM you've got should result in good performance, I have read again and again that following that rule of thumb has resulted in poorer performance for many users than it does when VideoMemorySizeMb is set higher than VRAM.
 
So, going back to the topic of this thread, I'm not 100% convinced that using AutodetectVideoMemorySize=true is the best recommendation for all users as the method to set ENBoost's video memory size, nor would I be happy to settle with recommending the ((RAM + VRAM) - 2048) formula, either.
 
No, I would say the recommendations should be based on system type (32 vs 64-bit), system RAM, and VRAM -- and those recommendations should be clearly labelled as a starting point which should be followed up with in-game testing and adjusting.
 
I've asked Boris a follow-up question about where all that "video memory" is allocated, and after I get a reply, then I plan on asking about the EnableCompression feature - because even after some more searching and researching, I don't have a clear picture of how it works, and I haven't found a clear explanation of why VRAM usage would go down when it is enabled.

Edited April 17, 2014 by keithinhanoi