Jump to content

STEP Investigates: The 3.1 gigabyte RAM Limit and Modding


Gyrotica

Recommended Posts

Hello! I come from the STEP <Skyrim Total Enhancement Project> forums. A couple months ago we did a detailed investigation into reports that Skyrim falls apart when it starts to use at or around 3.1 gigs of RAM, and what might contribute to that. After seeing some recent discussions on the Nexus forums, we figured that we hadn't adequately publicized those results, which are the following:

  • Skyrim will crash at or around a reported 3.1 gigabytes of RAM usage, which is fairly widely known.
  • Skyrim mirrors its active textures in memory, and since it is a 32-bit application with a 4GB memory limit, this constrains the total size of modded textures that are viably usable.
    • The exact VRAM:RAM ratio is not known, but one metric reported was a texture pack taking up ~500MB VRAM would consume approximately 430MB physical RAM.
    • The memory usage figures reported by Task Manager and Skyrim monitoring tools represents the "working set" RAM assigned to the Skyrim program. This is only a partial figure for the total amount of memory in use by Skyrim, and cannot be relied upon as an indicator of true memory usage, which cannot easily be determined. As the load of modded textures drives the memory use to the 4GB limit, the partial Working Set figure tends to report somewhere around 3.1GB, but this varies, and can only be used as a rough indicator.
  • When contacted, Bethesda indicated they had no intention of addressing the issue, which they described as a fundamental problem of 32-bit applications (though it is not necessarily clear if they were aware that we were inquiring about the mirroring issue rather than RAM overall).

We present this information with the hope that modders/mod authors will keep these limitations in mind when using/creating mods, especially texture-heavy ones. Those mods that take up less space will likely get more exposure, given that most modders will be using a heavily-modded game.

Without Skyrim's source code it is almost certain that neither the 3.1 gigabyte stability issue nor the RAM mirroring issues will ever be fixed.

Link to comment
Share on other sites

I'm not that technically minded with these sort of things, but I recall once when I had Windows XP running a dual-boot x86 and x64 systems with a 8Gb RAM pc, the 32-bit XP only had approx 3.25Gb RAM left after OS use. With that info I can only assume to mainly agree with Bethesdas 32-bit limitations statement, but I also guess it should really use all 4Gb if you have a 4Gb+ x64 system(?)

 

It's because of things like this that I personally can't wait for the next generation consoles with their 8Gb RAM systems - hopefully it should be inevitable that this'll positively affect pc users too with "better" hardware support and usage.

 

Thanks for your efforts and posting the results.

Link to comment
Share on other sites

I find it funny that this exact issue has not been resolved with Skyrim. I remember finding it quite annoying in Oblivion and in fact quitting my attempts to mod it finding that Oblivion would inevitably run into a ~3.2GB ceiling in sufficiently cluttered areas. Having just started Skyrim I am quite surprised that Bethsoft never learned.

Link to comment
Share on other sites

The loading of models and textures in both RAM and vRAM is due to DirectX9. DirectX10 and up make it so that the guff doesn't need to be loaded into RAM.

 

This might be possible to negate through the use of a wrapper, but that would be an absolute pain in the neck to develop. The creator of ENB might be able to, as (s?)he made a DirectX8-DirectX9 wrapper.

Link to comment
Share on other sites

  • 2 weeks later...

The loading of models and textures in both RAM and vRAM is due to DirectX9. DirectX10 and up make it so that the guff doesn't need to be loaded into RAM.

 

This might be possible to negate through the use of a wrapper, but that would be an absolute pain in the neck to develop. The creator of ENB might be able to, as (s?)he made a DirectX8-DirectX9 wrapper.

 

As a matter of fact ENBSeries 0.193 appears to include just such features. The following options were added as part of ENBSeries 0.193:

[MEMORY]
ExpandSystemMemoryX64=true
ReduceSystemMemoryUsage=true
DisableDriverMemoryManager=true

My limited testing, however, indicates it's not yet working. Still CTDing at ~3.2 Gigs Commit.

Link to comment
Share on other sites

  • 8 months later...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...