The textures in the UWP version of the game I’m helping with use between 2 to 5 times as much memory when run as x64 compared to x86. The difference in memory usage is much more significant than what you’d expect to see between regular x86/x64 apps. Is it possible for us to get texture memory usage on x64 closer to x86?
Info
A significant number of textures are loaded in the LoadContent method of Game1. At the end of the LoadContent method, the x86 version uses around 130MB RAM, while the x64 version will be using about 720MB at the same breakpoint. There are no architecture-specific conditional compiler symbols in the project, so the code and content are identical between the architectures.
After starting a new game and loading game world textures, memory usage on x86 settles around 370MB, and 1.2 GB on x64.
Textures are loaded using the standard Content.LoadContent(“texture/path”). We’ve confirmed that it’s the textures causing the memory increase by setting breakpoints where textures are loaded and watching the process memory. Also commenting out loading some of the larger textures saves hundreds of MBs on x64, and saves a proportionally similar amount on x86 (though less is saved as much less memory is used on x86 overall).
@ChrisBlackman Textures use barely any managed memory so they shouldn’t fill up RAM, but this might be related to the issue @gap9269 was having. ContentManagers use a scratchbuffer for loading textures so they don’t have to allocate a new array every time. When loading textures the buffer grows as large as required to fit the largest texture in RAM. That might be what’s happening here too, though 1.2 gigs is really, really, really, large. Are you loading some exceptionally large textures by any chance, like 5000x5000 or something? Or are you using multiple ContentManagers?
Ha, Chris is actually helping me out with a UWP port and that’s what this topic is about.
The largest we’re loading is about 4000x3000, and we’re loading a couple of them. The thing we’re curious about is why the memory usage is so much higher when running as x64 than it is when running as x86. This particular example is only using a single ContentManager. When we step through the LoadContent method and watch the memory increase, it is several times larger on the x64 version of the game. This is a problem due to the UWP’s limit of 1GB RAM on xbox.
Some stuff takes up twice the amount of space between 32-bit and 64-bit applications (I guess that should have been obvious), but now I’m trying to figure out what exactly in the contentmanager is doing that. When I get a bit of free time I’ll toy around with it again. I wonder if it has anything to do with the scratchbuffer that they use?
@Jjagg Do you know the scratch buffer fill to the size of texture’s compressed file size, or does it fill to the size of the textures uncompressed bitmap data (which would be 4 bytes per pixel)?
The scratch buffer isn’t the issue anyway, the behavior is the same on 3.4
I’m pretty stumped on this. Perhaps this is simply what you should expect when targeting the x64 architecture? The thing that is strange to me is how many times more expensive loading large assets is in x64.
I tested by loading 23 copies of a 4000x4000 texture in x86 and x64. The results are 93MB (x86) vs 1.6GB (x64).
@Jjagg Hmm, we’re not using a compressed texture format, but I assumed the mgcb is compressing the content with zip or something after processing, then decompressed on load. We have the “Compressed” property in the mgcb project root set to true, and the texture format of all textures is “Color”. I can’t find any documentation on the Compressed property, so I could be wrong about how it works
But continuing from @gap9269’s comment, do you think it’s possible the raw texture data is being stored in RAM on x64? Theoretically, the pixel data in those 23 4000x4000 textures would be around 1.4GB of memory (23 * 4000 * 4000 * 4 / 1000000000 = ~1.427), which is close to the 1.6GB the test project uses.