ACCEPTED ENBSeries (by Boris Vorontsov)

[TechAngel85]

What value does Boris's Vram Tool return on this Win 10 setup?

[Dark_wizzie]

Go to the page to see the photos on the reddit page to see what they look like up close. Too small here.

 

That is insightful. Is this testing with the latest Windows 10 version? Because I noticed that Microsoft fixed some major game issues with the latest version that i had had originally, and perhaps they silently changed this. Go to Settings --> System --> About and what is your version and build numbers?

10.0.10586.122

Version 1511

 

March 2nd version.

 

What value does Boris's Vram Tool return on this Win 10 setup?

Exactly as one would expect: 4064/11680 for DX9/DX11.

 

 

So, when the soft cap is reached, Skyrim will try to purge data from Vram as we can see in the Vram curve on the Win 10 picture w/ TR. Around that time, FPS drops. IO usage does not seem to increase. CPU usage elevated slightly. The major Vram staircase problem can be seen both in 3/3 runs w/ TR on Win 10, but also in practice when I was testing. Also note that in all runs on Windows 10, with or without TR, there is a Vram drop at the end of the run, with a corresponding drop in FPS. This Vram drop does not occur with Windows 7. However, w/o TR in 2/3 runs Windows 7 had a stutter a bit before where all Win 10 runs would have the Vram drop. It's unclear why it happens without TR and doesn't with TR. This caused TR FPS on 7 to be actually marginally higher than without.

 

Hopefully further testing will give us finer details.

Edited March 10, 2016 by Dark_wizzie

[Dark_wizzie]

Alright guys. I've made an update to my Reddit post.

 

FRAPS FPS: https://i.imgur.com/sXY8lMc.png

FRAPS Frame Times: https://i.imgur.com/Hsc2mnt.png

SPM Data Averaged: https://i.imgur.com/AFKHNuD.png

 

This is data from 10-11 runs without TR. I think FRAPS FPS data is more accurate than SPM's. I don't understand the frame time data, it's as if the data switched sides. Just for you guys, I've updated my Windows to the 3/8/2016 version.

 

I just spent the entire day benching Skyrim and dealing with Excel. 

Edited March 11, 2016 by Dark_wizzie

[DoubleYou]

Forgot about the VRAMTest tool for that.

 

Yes, 4064 for DX9.

~61792 for DX11 (this value seems to vary whenever I launch it). I really don't understand the DX11 value. I have 4gb VRAM and 16 GB RAM, so the max should be closer to 18000. Perhaps somehow it counts part of my SSD or something toward it??? Either that or it is simply buggy.

[Zlycher]

 

10.0.10586.122

Version 1511

 

March 2nd version.

 

Exactly as one would expect: 4064/11680 for DX9/DX11.

 

 

So, when the soft cap is reached, Skyrim will try to purge data from Vram as we can see in the Vram curve on the Win 10 picture w/ TR. Around that time, FPS drops. IO usage does not seem to increase. CPU usage elevated slightly. The major Vram staircase problem can be seen both in 3/3 runs w/ TR on Win 10, but also in practice when I was testing. Also note that in all runs on Windows 10, with or without TR, there is a Vram drop at the end of the run, with a corresponding drop in FPS. This Vram drop does not occur with Windows 7. However, w/o TR in 2/3 runs Windows 7 had a stutter a bit before where all Win 10 runs would have the Vram drop. It's unclear why it happens without TR and doesn't with TR. This caused TR FPS on 7 to be actually marginally higher than without.

 

Hopefully further testing will give us finer details.

 

Is there any updates on this issue? While this might have been a fringe issue, now that the Nvidia 1070 and 1080 are out, I think that this bug is highly relevant. I was planning on doing a ton of benchmarking for S.T.E.P, but if my 1080 is going to be throttled by Windows 10, I'll probably have to wait.

[Nebulous112]

No, Microsoft still hasn't fixed the bug. It is doubtful they ever will, IMO.

 

Unless you are running with a ton of 4K textures, the 4064 cap really shouldn't affect you too much.

[Zlycher]

Well in the spirit of internet activism I up-voted the bug report here https://connect.microsoft.com/VisualStudio/feedback/details/1263324/gpu-memory-allocation-limit-on-directx9-windows-8 

 

Semi-related to this discussion, do we know any details on the Skyrim remaster. My understanding is that Skyrim is in essence a dx9 game to keep all the consoles on the same platform. Since the remaster is mainly intended to get people on the newer consoles, is it feasible that the dx version would be bumped up?

[Nebulous112]

Yep, it will be DX11 so this bug will not be relevant for the Special Edition. As long as you own the base game and all DLC by October 28th it will be free in a separate listing in Steam (so it won't affect current games). SKSE and ENB binaries will need reworking, and mods will need to be saved in the new CK to work. So don't expect all mods to work right away.

 

There are a few threads kicking around with a bunch of info...I think maybe in the Games or Banter Inn forums.

[GrantSP]

Following the discussion on the SKGE page in Nexus a comment was made about our suggestions for certain settings and this wiki page was mentioned. The user said that:

 

 

SpeedHack

Enables/disables the ENBoost features found in the [MEMORY] section further down in the file. It is recommended to always have it enabled for stability and performance.

SpeedHack=(false, true)

is incorrect as the ENBoost features will still be loaded and ENBhost will still be found active in the list of running processes. This page says that ENBoost is enabled/disabled with:

ReduceSystemMemoryUsage=(false, true)

Perhaps its time for a check of all the ENB references and make changes to ALL our wiki pages as it seems we are conflicted in our recommendations.

[Joat_Mon]

 

On July 23, 2013 Boris made the following two statements:

 

"SpeedHack is default feature of ENBSeries, but it also one of the main for ENBoost. I never paid attention to performance with it enabled, just made it, but i think that users with low end pc and vanilla graphic must have it too, so ENBoost is the solution, less associations with graphics only, right? Anyway, to use the mod for graphics purposes, UsePatchSpeedhackWithoutGraphics=true must be set. UseDefferedRendering=true or false depends from antialiasing (false if you want it), performance and effects used."

 

 

"Speedhack removes functions calls which aren't required, so less driver overhead."

 

Which indicates to me that the setting is not related to the memory patch portion for ENBoost.

[Spock]

On July 23, 2013 Boris made the following two statements:

 

"SpeedHack is default feature of ENBSeries, but it also one of the main for ENBoost. I never paid attention to performance with it enabled, just made it, but i think that users with low end pc and vanilla graphic must have it too, so ENBoost is the solution, less associations with graphics only, right? Anyway, to use the mod for graphics purposes, UsePatchSpeedhackWithoutGraphics=true must be set. UseDefferedRendering=true or false depends from antialiasing (false if you want it), performance and effects used."

 

 

"Speedhack removes functions calls which aren't required, so less driver overhead."

 

Which indicates to me that the setting is not related to the memory patch portion for ENBoost.

I think Boris had a little twist in that sentence: He probably meant to use the mod for memory management purposes and not shaders set UsePatchSpeedhackWithoutGraphics=true.

What that setting most likely does (very easy to test by deleting the shaders and measuring the overhead) is disable all dx9 api call interceptions not related to ENBoost.

[Joat_Mon]

https://enbdev.com/doc_skyrim_presetconvertion_en.htm

 

ENBLOCAL.INI

 

This parameter toggle patch features only or patch with graphic modification. ENBoost users who want to to play with graphic enhancement also, must set it to true:

[GLOBAL]
UsePatchSpeedhackWithoutGraphics=true

Edited September 16, 2016 by Joat_Mon

[TechAngel85]

I've updated the SpeedHack section to read as follows:

Enables/disables certain DX9 functions not required by ENBoost in order to save some overhead, which could lead to better performance. It is recommended to always have it enabled.

Both the INI Guides need a good "one over". I haven't taken the time to tackle them, but will be on vacation soon and might look at them (no promises). The enbseries.ini Guide is still a far cry from being completed. I need some good ENB Authors to help with that and a few were, but the work is boring so they faded out quickly. I don't blame them. ::

[Dark_wizzie]

No, Microsoft still hasn't fixed the bug. It is doubtful they ever will, IMO.

 

Unless you are running with a ton of 4K textures, the 4064 cap really shouldn't affect you too much.

Apparently Kaby Lake and future processors will not officially support Windows 7 anymore. Hopefully nothing bad happens. I paid a lot for my PC to try to minimize every stutter and I don't want it to be limited to Microsoft's DX9 bug and their unwillingness to support 7.

[TechAngel85]

Apparently Kaby Lake and future processors will not officially support Windows 7 anymore. Hopefully nothing bad happens. I paid a lot for my PC to try to minimize every stutter and I don't want it to be limited to Microsoft's DX9 bug and their unwillingness to support 7.

I have no plans to move away from Windows 7 or Haswell for some time. Windows 7 support will completely end in 2020. I'll likely remain on Windows 7 for at least until SSE is more fully supported by the modding community. As for my processor, the Haswell architecture has been shown to outperform it's successors in many applications. I have yet to even have the need to apply an overclock to my K-version i5. The minimal gains have yet to be worth the time and effort. The main benefit of the Haswell successors are the lower TDPs which I'm not concerned about.