Jump to content

[1.0][Release-5-0][April 28, 2015] Active Texture Management - Save RAM!


rbray89

Recommended Posts

So I have a question. I just downloaded the build from about 40min ago. I was eagerly awaiting this, as .25 seems to be more hungry than .24 was. I am running far fewer mods than I had been, but when playing i was right around 3GB. I could play a bit before it would run out of RAM and crash.

I did the openGL thing and it dropped to under 2GB which helped in the meantime.

I just installed ATM (aggressive not basic) and the game crashes with an out of memory error before it finishes loading.

Here is my output log http://1drv.ms/1uJqBlL

Link to comment
Share on other sites

I just tried the new basic build and my memory use went from ~2.3 Gig to ~2.8 Gig. It's making the cache but it is actually increasing memory usage. I removed to to see what my original memory usage was so I don't have a log but I can re-install and get the log if needed.

Link to comment
Share on other sites

So I have a question. I just downloaded the build from about 40min ago. I was eagerly awaiting this, as .25 seems to be more hungry than .24 was. I am running far fewer mods than I had been, but when playing i was right around 3GB. I could play a bit before it would run out of RAM and crash.

I did the openGL thing and it dropped to under 2GB which helped in the meantime.

I just installed ATM (aggressive not basic) and the game crashes with an out of memory error before it finishes loading.

Here is my output log http://1drv.ms/1uJqBlL

Log says you've loaded two versions of ModuleManager in your GameData. Remove v2.5 (keep 2.5.1) and try running again, see if you get better results.

Link to comment
Share on other sites

Log says you've loaded two versions of ModuleManager in your GameData. Remove v2.5 (keep 2.5.1) and try running again, see if you get better results.

Removing 2.5 made no difference.

Man .25 has been frustrating (not this mod, not complaining about ATM). Just in general. I am running less than half the mods I ran in .24 and fewer mods that I ran without even needing ATM. If squad is gonna bloat this game any more, we are gonna need a stable 64bit version.

Link to comment
Share on other sites

Log says you've loaded two versions of ModuleManager in your GameData. Remove v2.5 (keep 2.5.1) and try running again, see if you get better results.

i doubt this is the issue. modulemanager has a long history of safely disabling older versions of itself. Definitely remove it, but there's something else going on. Your log clearly shows an out of address space condition:

namicHeapAllocator out of memory - Could not get memory for large allocationCould not allocate memory: System out of memory!Trying to allocate: 1398104B with 32 alignment. MemoryLabel: Texture
Allocation happend at: Line:411 in
Memory overview


[ ALLOC_DEFAULT ] used: 298914531B | peak: 0B | reserved: 326705928B
[ ALLOC_GFX ] used: 728248622B | peak: 0B | reserved: 755820230B
[ ALLOC_CACHEOBJECTS ] used: 193832B | peak: 0B | reserved: 12582912B
[ ALLOC_TYPETREE ] used: 0B | peak: 0B | reserved: 0B
[ ALLOC_PROFILER ] used: 536076B | peak: 0B | reserved: 8388608B

Oddly, the memory summary shows 2032 MBs in use and reserved. are you running on a 32-bit version of windows?

Link to comment
Share on other sites

i doubt this is the issue. modulemanager has a long history of safely disabling older versions of itself. Definitely remove it, but there's something else going on. Your log clearly shows an out of address space condition:

namicHeapAllocator out of memory - Could not get memory for large allocationCould not allocate memory: System out of memory!Trying to allocate: 1398104B with 32 alignment. MemoryLabel: Texture
Allocation happend at: Line:411 in
Memory overview


[ ALLOC_DEFAULT ] used: 298914531B | peak: 0B | reserved: 326705928B
[ ALLOC_GFX ] used: 728248622B | peak: 0B | reserved: 755820230B
[ ALLOC_CACHEOBJECTS ] used: 193832B | peak: 0B | reserved: 12582912B
[ ALLOC_TYPETREE ] used: 0B | peak: 0B | reserved: 0B
[ ALLOC_PROFILER ] used: 536076B | peak: 0B | reserved: 8388608B

Oddly, the memory summary shows 2032 MBs in use and reserved. are you running on a 32-bit version of windows?

Nope 64bit Windows 8. 12GB RAM 8 GB free before starting. I was watching KSP's memory usage while loading and it would hit 3.4GB freeze then crash.

Link to comment
Share on other sites

Ah bummer, I guess I have to report it's not working for me either. I just ran a test with the ATM folder in and out of the game data folder. (I left the BoulderCo folder alone)

Memory use reported by Windows Task Manager:

==============================

Without ATM: 1.97 gb

With ATM: 3.07 gb

==============================

(Using opengl, non-aggressive ATM)

It also crashed on me once, which I suspect was because I had internet explorer hogging some of the 32-bit memory at that time, causing a memory crash. It's worth mentioning that windows-64 uses 32-bit Internet Explorer by default for some reason. So I think it's probably a good idea to close IE whenever running KSP.

I can produce a log if anyone wants it.

On a side note, I am not a programmer, but I seems like a simple way for Squad to address memory issues might be to not load the entire parts library upon launching the game, and just use them as-needed. :)

Link to comment
Share on other sites

I'm having the same problem as goldenpsp. EXACTLY the same problem. I'm running Windows 7 64 bit, though, and I only have a total of 4 GB of ram total.

So a little bit about the way 64-bit versions of windows allocates ram to 32-bit processes. the 32-bit part of that is the largest number the program can understand. with a 32-bit number, you can reach almost exactly 4 gb of ram. in this 4 GB address space (the technical term) windows must fit all of the functions that the program needs, and all of the textures, images, models, code, mapped files etc that the program uses to run itself. this 4 GB address space must cover everything the program needs, because the program simply doesn't have numbers large enough to look anywhere else.

This 4 GB address space is why 32-bit versions of KSP crash with an out-of-memory error around 3.5 GB, even when you have 8 or 12 GB available to the operating system. the program is using 3.5-ish, and relocated windows APIs, hardware interfaces, and other system things that the programs needs to use are using the remained. this is also the reason why the community pushed so hard for a 64-bit version, and why we're all so disappointed in it's stability. 64-bit numbers can address something on the order of 16 million terabytes, well in excess of any currently existing system.

Something is using that ram, but it doesn't appear to be KSPs memory allocation.

[...] On a side note, I am not a programmer, but I seems like a simple way for Squad to address memory issues might be to not load the entire parts library upon launching the game, and just use them as-needed. :)

Ya, this would not work. because it's running out of address space, the program would need to release the files as well, which would force them to be reloaded from disk just like during startup. basically you would see the same loading screen at boot time whenever you change scenes between the VAB and the launchpad.

Edited by AetherGoddess
Link to comment
Share on other sites

I will say I also went back to the patch posted a few pages back and things are working now

No ATM 3.1GB, could play a short time before crashing

Latest ATM, crashing at start

Patch from a few pages back, Running solid so far around 2GB RAM

Link to comment
Share on other sites

I would suggest using Sarbian's patch until I can figure out what KSP is doing internally now.

Before, they would read from the file tree in KSP that I could modify... now it looks like they might be grabbing it before I can get to it.

Link to comment
Share on other sites

I would suggest using Sarbian's patch until I can figure out what KSP is doing internally now.

Before, they would read from the file tree in KSP that I could modify... now it looks like they might be grabbing it before I can get to it.

Well, Sarbian's patch didn't work for me. I already tried it. I'll note that the loading process got farther than it did with the 'official' update, but still locked up out of memory.

@AetherGoddess - yeah, I'm aware of the whole 'running a 32 bit application in Win64bit' thing, this ain't my first rodeo here. I was just informing everyone concerned about my system setup. The point is that with ATM installed (and functioning properly), I shouldn't be having memory problems AT ALL.

Ahem, anyway, it looks like no KSP for me this weekend, regardless. Bummer. :(

Link to comment
Share on other sites

So it looks like the guys who are using openGL and ATM are having problems right ? But guys with directx and ATM are OK ?

I don't know, honestly. It seemed to work just fine for me on first load. On subsequent loads, though, my memory usage went back up to over 3gb. So I have no idea what's going on...it worked, then it didn't. I'm going to try the patch and see what happens with that, but if all else fails OpenGL drops my 3.3gb load to 1.1 gb. So there's always that to fall back on.

Link to comment
Share on other sites

So... as far as I can tell, I won't be able to stop KSP from loading (or re-loading) textures. It will always load them.

We have two options:

1) re-load textures after KSP has already done this. This means considerably longer loading times. (standard KSP load time + white screen loading time)

2) over-write the textures before KSP can load them. This means the file system will be altered. I might be able to put the textures somewhere else, but it will result in having to re-manage textures.

Link to comment
Share on other sites

So... as far as I can tell, I won't be able to stop KSP from loading (or re-loading) textures. It will always load them.

We have two options:

1) re-load textures after KSP has already done this. This means considerably longer loading times. (standard KSP load time + white screen loading time)

2) over-write the textures before KSP can load them. This means the file system will be altered. I might be able to put the textures somewhere else, but it will result in having to re-manage textures.

But if KSP is re-loading textures why does the previous version and the patch posted earlier seem to work as expected?

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...