3rd person stuttering

[Sahiley]

Hi Boris,

just wanted to thank you for you tools that made my beautiful Skyrim stutter-free even with 4K textures and 7GB RAM and 7GB VRAM usage. Screen

I was wondering if anybody mentioned to you that Skyrim has problem with stuttering during cell loading when loading too much LOD textures and objects. It only happens while being in 3rd person camera (doesn't happen in first person).
Sheson wrote why it happens and couple of his solutions with drawbacks here.
Is there anything you could do about it ?

Bonus question if you find any spare time (plz correct me if i make any wrong statements)...

Skyrim is dx9 game and saves textures and geometry in shared VRAM {physicall VRAM+tesv.exe (RAM)}. enbhost.exe process allocates textues from tesv.exe in it's own memory pool thus saving us from infamous tesv.exe 3.1GB RAM usage crash. If I set EnableUnsafeMemoryHacks=1, enbhost.exe process is not being used and your hack tries to allocate all textures and geometry in VRAM only. What could happen that people still reach tesv.exe 3.1GB RAM limit even when having EnableUnsafeMemoryHacks=1 ?
(we know hack is working because it eliminated stuttering which is otherwise present when it's disabled)


Best regards, gonna donate what i can again, when SSE gets some new features.

[ENBSeries]

Sorry, i don't want to bother with bugfixes, dont' remember anything anyway. From renderer side there is nothing special happens between third ans first person modes, just extra drawing of 1rd person models with differently scaled scene. Maybe game somehow wrongly set priorities for first person models and update/reload them often when transition occur. Probably it worth to check first person mode, but when some npc is also near to camera, maybe not player causing the issue, but any character.

What could happen that people still reach tesv.exe 3.1GB RAM limit even when having EnableUnsafeMemoryHacks=1 ?

EnableUnsafeMemoryHacks=true or false doesn't matter about tesv ram usage, in both cases it is not used much. If somebody have problems with memory limit even with this hack, i can try get more free memory, but not much, maybe 200-500 mb only.

PS: there is no 3.1 gb limitation, it's just wrongly measured amout of ram usage, 4 gb it is.

[Sahiley]

Sorry, i don't want to bother with bugfixes, don't remember anything anyway

Perfectly understandable. I'll be sure to test 1st person with character near by as well.

EnableUnsafeMemoryHacks=true or false doesn't matter about tesv ram usage, in both cases it is not used much

On my Windows7 64bit and cards (970,1070, r9 390x), driver fills tesv.exe RAM pretty fast if I use 4K textures (my VRAM 8GB is not being filled first, RAM and VRAM get filled almost in same time in 1:1 ratio), and I reach tesv.exe 4GB RAM mark already when loading a save. ->Screen<- (task manager only sees 3.2GB). ENBboost features fix that limit but both VRAM and RAM usage ratio is always almost 1:1. VRAM~=tesv.exe+enbhost.exe+enbhost.exe.
Is this expected behaviour ?
I see it as textures having same instance saved both in VRAM and RAM (tesv.exe or enhost.exe(if ENBoost enabled)), and when EnableUnsafeMemoryHacks=true, texture instance should be saved only in VRAM thus reducing RAM usage(not reducing tesv.exe RAM usage but reducing enbhost.exe usage(actually then there is no need for enbhost.exe to exist)).

If we use this scrrenshot as example with precious ENBboost enabled:
tesv.exe= 2.1GB RAM
enbhost.exe= 4GB RAM
second enbhost.exe= 1.7 GB RAM

This is where i get confused...
If I enable memory hacks, all copies of textures that resided in both of my enbhost.exe processes (4GB+1.7GB), now exist in VRAM only or they go back to VRAM+tesv.exe (shared memory) ?
Because it seems once UnsafeMemoryHacksare enabled, tesv.exe fills up again (doesn't stay at 2.1GB like it was with eNBboost enabled).

i can try get more free memory, but not much, maybe 200-500 mb only

I suppose you are talking about transferring geometry along with textures ?
Is there a chance some players would benefit more then 200-500 MB if their modded Skyrim stores more geometry instances then vanilla Skyrim ?
Regardless, think that would be a great update if you could also keep previous update still available, so that communality can do various tests on both.

[ENBSeries]

Is this expected behaviour ?

No, it is abnormal (if ReservedMemorySizeMb is low). You can check how much memory used by enbhost.exe, if it's very low, then simply do not work (antivirus for example f* around or all those afterburners).

If I enable memory hacks, all copies of textures that resided in both of my enbhost.exe processes (4GB+1.7GB), now exist in VRAM only or they go back to VRAM+tesv.exe (shared memory) ?

They can't go back, they can't exist in enbhost.exe at all if EnableUnsafeMemoryHacks=true, everything is placed in to vram only. I just checked again, everything works as it should, with vanilla game 1.5gb usage of tesv process when this parameter enabled.

I suppose you are talking about transferring geometry along with textures ?

Yes

Is there a chance some players would benefit more then 200-500 MB if their modded Skyrim stores more geometry instances then vanilla Skyrim ?

No idea, i never measured amount of memory used, because never tried to install too many mods and increase drawing distance and ugrid... something.

[ENBSeries]

Did a test, somehow don't see any difference in memory usage if push meshes to vram, probably directx or driver remove them from process address space.

[Sahiley]

Did a test, somehow don't see any difference in memory usage if push meshes to vram, probably directx or driver remove them from process address space.

No difference both in VRAM and RAM ? So most likely directx or driver already had them moved to VRAM even without the hack ?
Can we try it just to see if it acts differently on our systems ?
I'll be coming home from vacation in couple of days, and I'm eager for some testing.
Also have to try again to see my vanilla tesv.exe RAM usage to compare it with yours.

[ENBSeries]

No difference by ram. Yes, we can try on other system