MontyMM

Thanks for the update. Could I just ask, because I've seen a few people mention it now, do you plan to consolidate all the different files into one release?

"Police, freeze! Put your hands where they can be seen!" xDI think he got it already, but thanks for the reminder (I was not 100%ly sure that this was actually written down anywhere here on the boards) :P Yeah - don't worry - I'm not turning into that guy! But I do want to point out that keeping threads readable is very important, and that it's not just a matter of preference and style - we do have rules on this, and for good reason.Â

Please read the STEP Community Citizenship Guide. In particular: - Please use standard English grammar, punctuation, and capitalization. - Any post with the following will be immediately removed. PLEASE DO NOT use excessive amounts of large, colorful, or otherwise annoying text just to emphasize your words. These rules are to keep threads readable for everyone, and to keep things coherent for our non-english speaking friends. Please edit the problematic posts in this thread.

Oh. I haven't been around to observe their patterns for a while. Pity - I was quite excited when I saw that!

I like the sound of this one. Seems they've taken seriously the idea of fixing and improving some fundamentals. I'll be very curious to see how the "memory and stability improvements" impact on the issues we've been looking at.

I think it's a very promising idea. There are already active data centres testing a similar concept with mineral oil. In fact, my new PC is very lucky that it didn't end up in one of these. It's the sort of loopy thing I like to do.

Excellent. Death to Flash!

There's no question that there's a 4GB limit, but I think there are still many open questions to answer here.

I'm assuming for a moment that the RAM limit crash does exist. What I'm curious about is whether it might be the Skyrim engine deciding to cache the textures in RAM (in which case there is the slight possibility of this being configurable) or whether this is certainly an inescapable behaviour of DX9. There might be a techie around here who can testify.

Just to clarify - I'm not questioning whether Skyrim is DX9/10. The article seems to suggest that Windows was patched to improve the memory handling of legacy DX9 applications, without updating them to DX10.Â

I think this is a key question. The wording in the KB article (attached to a hotfix), suggests that Windows itself was modified to improve the problematic memory allocation of DX9: If an application creates its own in-memory copy of its video resources, or the application uses DirectX 9 or an earlier version, the virtual address space contains the WDDM video memory manager's virtualized range and the application's copy. Applications that use graphics APIs that are earlier than DirectX 10 and that target GPUs that have large amounts of video memory can easily exhaust their virtual address space. To address this problem, Microsoft is changing the way that the video memory manager maintains the content of video memory resources. This change is being made so that a permanent virtual address range does not have to be used for each virtualized allocation. With the new approach, only allocations that are created as "lockable" consume space in the virtual address space of the application. Allocations that are not created as "lockable" do not consume space. This approach significantly reduces the virtual address space that is used. Therefore, the application can run on large video memory configurations without reaching the limits. This seems to leave open the question of how much of Skyrim's memory texture caching is inherent to its DX9 origins, or a (possibly configurable) feature of the engine. Perhaps someone knows with certainty the DX9 memory behaviour on later versions of Windows?

I have not been formally recording the results, but since I returned to Skyrim a few weeks ago I've been monitoring it's behaviour. In my case there is no doubt - adding textures does increase both VRAM & RAM usage in a very close ratio. At the moment, my Skyrim setup is in bits, but I will do some proper benchmarks at a later date. As Viking is at pains to point out, there is something significant going on here, but so far we know very little. One fundamental point is that correlation does not prove causation - although the crashes appear to occur at a certain level of memory utilisation, it is possible that other less visible demands increase in tandem with memory usage, and these could be implicated. That said, I think memory is certainly a suspect. In the opinion of ENB Boris, many games suffer from bugs with addressing memory above 2GB. I think this is worth considering, since it is possible that (assuming memory is the problem), it could be an implementation problem rather than a fundamental limitation, which would tally with the unexpected and varying limiting figure of 3 - 3.5GB usage. Â

Seems like another winner to me, with an efficient implementation.

Lucky Helen.

Thanks Gyro, but at the moment I'm not really looking into this. I'm pretty busy making all the patches for Semi-Automatic STEP (I was going to do it a quick way, but I've decided to do it in a more flexible way to try to suit everyone.) I do think it's somthing worth playing with though. Most attempts at tweaking the settings have been aimed in the opposite direction - to force Skyrim to use MORE memory, which seems desirable at first glance. But it would be interesting to see what happens if it can be tweaked to use less.

Just to pile on more unknowns though, we don't know how much of the texture RAM usage is the result of Windows/DX behaviour, and how much is dictated by the engine. It is conceivable that there could be Skyrim settings that reduce the amount of data cached in RAM. One experiment I performed was with raised ugrids. Usually you would set the ugrids with a corresponding setting for exterior cells to buffer, and VRAM & memory usage goes up sharply. I tried omitting the exterior cell buffer increase to see if my SSD could serve up the data fast enough, without buffering it to RAM. I found that it could do a pretty good job - memory use went down, disk access went up, and there was a little bit of slight hitching for the loads. Now, this is all experimenting in the dark, and I'm not advocating that anyone messes with ugrids at all, but there may be settings that could reduce Skyrim's caching further.

I'm not suggesting that VRAM is the issue - I was taking the high usage as a possible indication of increased ugrids, which would have been a likely suspect. I don't think that VRAM is likely to be a problem here. Unfortunately, DX9 based games will use main memory to mirror some textures, which can cause problems. Interesting article here. It is also suggested that games that were written with the 2GB cap in mind often have bugs that affect the addressing of higher memory space. Sadly, I think we're hitting the limitations of a creaky engine here. I'm afraid that only a major update from Bethsoft can solve these problems (they originally promised a DX11 version of the game, but I'm not holding my breath.) Of course, we cannot be certain that memory is the culprit in your case.

Just my personal feeling on this mod - I don't really like the idea, and I would rather exclude it from the project entirely. Not looking to start a huge debate on the subject, just my take on it.

I'm not at all convinced about that tweak. I tried it, and then looked into it. Here is the definition of that setting: iMaxAllocatedMemoryBytes This is the maximum amount of memory the VM will allocate in total for stack frames. If an allocation would push memory usage over this limit, the VM will instead wait for more memory to be freed. Increasing this value may improve performance in high-stress situations with lots of scripts running, but will use more memory. Note that it is possible to exceed this value temporarily while loading a save game due to slightly different allocation ordering. Max: 2147483647 (2GB) Default: 76800 (75kB) What RCRN is recommending doesn't tally with an understanding of this definition.

Moved to Support form.

Have you tweaked your ugridstoload settings? My VRAM usage doesn't usually go that high unless I'm experimenting with higher ugrids.

I'd be very surprised indeed if SSDs were to blame. Is everyone also using Mod Organizer? I'd be curious to know whether switching to Wrye Bash improves this.

I agree. A patient approach seems the most sensible for the Skyrim lighting developments at the moment. As you've probably discovered, COT can throw curveballs at your ENB, as it creates some lighting conditions that don't crop up in vanilla. Bear in mind though, if you're thinking of STEP, that it's Relighting Skyrim we're favouring as standard, not RLO. RLO is brilliant, and many of us use it personally, but RS keeps much closer to vanilla lighting in line with STEP goals. I suspect we'll have RS as the default, and RLO in an optional "Realism Pack". It'd be great to have more tailored ENBs for either.

Good work. I know what a desktop like that looks like! It looks very much like Relighting Skyrim is emerging as the favoured default lighting solution for STEP, and I suspect that Climates of Tamriel will make a return somewhere in the mix. If I were making an ENB profile for STEP purposes, I'd want it to be well-tuned to that combination. By all means have a go - with the introduction of lighting packs it would be good to have some other vanilla-friendly options besides Skyrealism.

Well, there's not much to go on, but one of the things that will cause instant crashes is errors in the ini files. If you've edited those, I would start by making sure everything's correct.