CTD and Performance patch ENBoost (by Boris Vorontsov)

[Octopuss]

Which setting enables the memory manager? I couldn't find anything.

Is it the cryptic "DisableDriverMemoryManager" by chance?

[keithinhanoi]

Which setting enables the memory manager? I couldn't find anything.

Is it the cryptic "DisableDriverMemoryManager" by chance?

Well, it depends on what Boris means when he says "memory manager," which is why I asked him. Still waiting for the answer.

Anyhow he's talking about one of two possible things, either:

1. The main ENBoost additional dynamic memory allocation, launching 1 instance of enbhost.exe for every extra 4GB needed to cache textures and object geometry. This is enabled with two settings in enblocal.ini:

[PERFORMANCE]SpeedHack=true[MEMORY]ReduceSystemMemoryUsage=true

or

2. Enabling his own video memory manager using the setting:

[MEMORY]DisableDriverMemoryManager=true

The reason why the setting is named Disable... is because it disables the video memory manager that your videocard driver provides. For example, if using an AMD card, the Catalyst driver's memory manager is disabled with the above setting, and Boris' version takes over.

According the Boris, the advantages of using his video memory manager is that it will ignore errors that would normally lead to CTDs when using your video driver's memory manager. However, this comes at the potential cost of decreased performance (lag / stuttering) or even long pauses in-game.

Whether disabling your native video card driver's memory manager will work well for you highly depends on your make of GPU and what driver you have installed for it.

 

There ya go - a sneak peak to my ENBoost (enbhost.ini) settings explanations that I'm working on.  :happy:

[Kuldebar]

The predictable posts begging Boris to put the ExpandSystemMemoryX64 setting back in the build are a tad bit ridiculous.

 

They pretty much lay the blame on that one guy who posted about a possible SKSE Alpha and ENBoost setting conflict. Yes "that one guy" also criticized Boris's dismissive attitude and reaction to the suggested possibility of there being a problem. Well, you can't get anymore dismissive to concerns than by pulling a central feature from your build without making any attempt to work things out with other parties.

So when Boris pulled the parameter with a slight acknowledgement of there being a possible issue, the pitchfork-bearing villagers more or less completely ignored that admission, choosing to disparage the only person (on their forum) who actually suggested that SKSE Alpha and that particular ENBoost parameter might have some undesirable interactions.

Taking your marbles and going home is your right, but throwing temper tantrums and having people cheer you on...well, that's the type of enabling behavior we could use less of in the world today. Working with people will always take more effort than just shutting things down.

 

As far as I am concerned, the decision Boris made is either:

• an admission that there was actually a problem with ExpandSystemMemoryX64 parameter
•  a decision based on a vindictive or spiteful reason

 

So, take your pick, both reasons suck.

Yes, he can get mad and take his marbles home, it's his right, but it's not a good way work with other people in order to resolve problems.

His work is not taking place in a vacuum; the sheer success, value and popularity of his software necessitates the equal need for coexistence along with the awesome of work of so many others.

We don't need to pick sides, planting flags is a generally bad idea in the field of ideas.

[keithinhanoi]

Boris never claimed there would be no issue with the ExpandSystemMemoryX64 feature.
 

He made it for himself, and shared it because he thought it would be useful to others. But having read his posts on the feature, he made it pretty clear that he was sure it wouldn't work for everybody.
 

Then with binary v0.246 he changed the default in enblocal.ini to disable it, apparently due to too many complaints from people. We don't know if some number of people complained by PM. He made it sound like people were ganging up on him, he didn't like it, and finally *bam*, a knee-jerk reaction.
 

So now suddenly we're getting vocal pleas from a few people for whom (to their suprise) the feature seems to have made their game much more stable. But I don't understand the quick blame on jonwd7 for causing the situation other than the inability to read around. Posts by Boris on the sheson's memory patch fix thread show that he had done some tests and decided the SKSE alpha introduced some incompatibility with the feature. I think there's more to this than that one high-profile spat.
 

With the recent spate of posts asking for Boris to put it back and piling blame on "that guy", my ironic side wonders if they've got Footprints in their mod lineup and have no idea "that guy" is the author.

[Kuldebar]

Keith, well and fairly said...I actually didn't realize that "that guy" was the author of Footprints.

I just don't like making people out to be the "bad guys" for the sake of needing scapegoats. And yes, that includes dear Boris, I do point out his prickly porcupine nature at times but my intention is to not make him out to be the "bad guy" in this either.

He simply is notably impatient with people at times and as you said, somewhat prone to reactive changes in directions...I get whiplash. :)

[Octopuss]

Could someone give me a brief summary of the drama please? What the heck actually happened, besides that setting being removed?

It smells of the classical internets.

[Kuldebar]

@Octopuss:

 

Jonwd7 is getting group hated by people over the decision Boris made to remove the ExpandSystemMemoryX64 from enb builds. Typical scapegoating with some added flavors of rabid fan-boy fervor serving to overshadow the simple but very relevant fact that it was Boris alone who made the decision to pull the feature...and no one else.

 

I think the hate-mongering is really misguided and have been surprised to see some of the more level headed posters over on the enbdev forums jump into the fray casting condemnations on the person who originally posted about a potential problem with ExpandSystemMemoryX64 and SKSE Alpha, in the same post Jonwd7 also pointed out that Boris was being dismissive and condescending of others who brought up about the possibility of a conflict.

 

The fact of the matter is, nothing got fixed or verified, Boris just got fed up and pulled the feature. In my opinion, he should have just let things be, and it would eventually get sorted out, even if he didn't desire to address the issue himself.

 

Keith's posted the best synopsis:

 

 

But having read his posts on the feature, he made it pretty clear that he was sure it wouldn't work for everybody.
 

Then with binary v0.246 he changed the default in enblocal.ini to disable it, apparently due to too many complaints from people. We don't know if some number of people complained by PM. He made it sound like people were ganging up on him, he didn't like it, and finally *bam*, a knee-jerk reaction.
 

So now suddenly we're getting vocal pleas from a few people for whom (to their suprise) the feature seems to have made their game much more stable. But I don't understand the quick blame on jonwd7 for causing the situation other than the inability to read around. Posts by Boris on the sheson's memory patch fix thread show that he had done some tests and decided the SKSE alpha introduced some incompatibility with the feature. I think there's more to this than that one high-profile spat.
 

With the recent spate of posts asking for Boris to put it back and piling blame on "that guy", my ironic side wonders if they've got Footprints in their mod lineup and have no idea "that guy" is the author.

[Aiyen]

Based on how jonwd7 inititally posted his criticism then it is obvious that he is getting the blunt of the hate. It was highly immature and yet another case of someone blaming Boris for their game not working, without any real backing by other people. 

And even with how hot the topic is now, then nobody is coming with more proof that this feature is bad, only more people who have issues with it not being there. Also on the various preset pages I have visited this seems to be the general trend.

Also people in general cant understand why one would need to remove a feature that can just be set to false for the people who have issues with it, since Boris did point out many times that if you have stuttering issues then that feature is one you should try first.

Since Boris is currently on a small sabbatical of sorts playing other games and ignoring everything then one can also assume he is just doing it to be funny... in his own sort of semi cruel way! If that is the case then I can get behind it, since I think it rather amusing. 

[Kuldebar]

The storm has passed, it's back:

 

ExpandSystemMemoryX64

[phazer11]

It's back? You mean he actually removed it at some point?

[Kuldebar]

It's back? You mean he actually removed it at some point?

Yea for about 3 days a few days in the previous build when he took a break from coding. (my timescale is skewed, too much Skyrim time) ;) Timescale=10

Edited March 5, 2014 by Kuldebar

[EssArrBee]

It's back? You mean he actually removed it at some point?

He even removed the proxy section once. Then he added some intro text that he didn't support using the proxy. Then he switched it back to normal.

[phazer11]

Odd. I didn't notice anything different the other day. Oh well at least it was added back.

[keithinhanoi]

It's back? You mean he actually removed it at some point?

Yes, and apparently it's now improved with "error check when enabled" - see his entry for 4 March 2014 on the ENB news page.

 

I can also report back that he replied to my question to clarify what he means when he says "memory manager." He is referring to the main ENBoost feature that is enabled with speedhack=true & ReduceSystemMemoryUsage=true in enblocal.ini. (source post here)

 

So, I can now put his previous comment about the usefulness of the ExpandSystemMemoryX64 setting in better context:

 

ExpandSystemMemoryX64 is useful, but in practical terms it is much less useful than if you enable the main ENBoost memory manager (via speedhack=true & ReduceSystemMemoryUsage=true in enblocal.ini) with ExpandSystemMemoryX64 disabled.

 

That said, a few people on the ENBForum thread for ENB for Skyrim v0.251 reported that they have fewer crashes with ExpandSystemMemoryX64 enabled, even though they have ReduceSystemMemoryUsage enabled as well.

 

Interestingly, Boris has also explained the way that the DisableDriverMemoryManager setting works in further detail in the same post I mentioned above, and also in this follow-up post responding to my asking for clarification.

 

Taken all together from his responses, he seems to saying that:

 

Your installed video card driver and DirectX9 normally manage video memory resources, including:

• Moving object geometry and textures from system RAM to video RAM (VRAM)
• Deleting object geometry and textures from VRAM when it gets filled
• Monitoring usage of geometry and textures to reduce level of data transfer (presumably by keeping the most frequently used data)

If DisableDriverMemoryManager is set to true in enblocal.ini, then Boris' driver adds a third method of video memory resource management that improves on older obsolete memory management functions. The video memory management provided by your videocard's driver and DirectX9 are still used for the portion of your VRAM set aside with the ReservedMemorySizeMb setting in enblocal.ini, in oder to maintain stability with other applications and processes that still access your VRAM while Skyrim is running.

 

That's the best I can understand of his explanation, but it's not totally clear to me that Boris' method of video memory resource management is the only one used for Skyrim (outside of the VRAM set aside with the ReservedMemorySizeMb setting.) Maybe I will try asking...

[DoYouEvenModBro]

Yes, and apparently it's now improved with "error check when enabled" - see his entry for 4 March 2014 on the ENB news page.

 

I can also report back that he replied to my question to clarify what he means when he says "memory manager." He is referring to the main ENBoost feature that is enabled with speedhack=true & ReduceSystemMemoryUsage=true in enblocal.ini. (source post here)

 

So, I can now put his previous comment about the usefulness of the ExpandSystemMemoryX64 setting in better context:

 

ExpandSystemMemoryX64 is useful, but in practical terms it is much less useful than if you enable the main ENBoost memory manager (via speedhack=true & ReduceSystemMemoryUsage=true in enblocal.ini) with ExpandSystemMemoryX64 disabled.

 

That said, a few people on the ENBForum thread for ENB for Skyrim v0.251 reported that they have fewer crashes with ExpandSystemMemoryX64 enabled, even though they have ReduceSystemMemoryUsage enabled as well.

 

Interestingly, Boris has also explained the way that the DisableDriverMemoryManager setting works in further detail in the same post I mentioned above, and also in this follow-up post responding to my asking for clarification.

 

Taken all together from his responses, he seems to saying that:

 

Your installed video card driver and DirectX9 normally manage video memory resources, including:

• Moving object geometry and textures from system RAM to video RAM (VRAM)
• Deleting object geometry and textures from VRAM when it gets filled
• Monitoring usage of geometry and textures to reduce level of data transfer (presumably by keeping the most frequently used data)

If DisableDriverMemoryManager is set to true in enblocal.ini, then Boris' driver adds a third method of video memory resource management that improves on older obsolete memory management functions. The video memory management provided by your videocard's driver and DirectX9 are still used for the portion of your VRAM set aside with the ReservedMemorySizeMb setting in enblocal.ini, in oder to maintain stability with other applications and processes that still access your VRAM while Skyrim is running.

 

That's the best I can understand of his explanation, but it's not totally clear to me that Boris' method of video memory resource management is the only one used for Skyrim (outside of the VRAM set aside with the ReservedMemorySizeMb setting.) Maybe I will try asking...

Can you please help write/update the STEP ENB Guide, if you don't contribute already.