When i started development of my game I was using a iPod Touch 1st Gen (3.0), iPod touch 2nd Gen (3.1.2) and a iPhone 3Gs (3.1.3) - Since then I have acquired a iPhone 4 and a iPad. I continued development of my game on these newer devices but have recently gone back to testing on the older models as I am getting close to submitting my game to Apple.
Now I am running into an issue where these older models are consuming significantly more ram then the newer models.
More then double (at the point of the crash) . Also the allocation seem quite different
3Gs
iPod 2nd Gen
4MB memory allocations on older devices not found on newer one?
Any one seen similar issues? Was hoping not to exclude these older models.
We’ve had same kind of troubles in our actual project. The older devices are much more slower and we were loading all the assets as fast as possible which lead to a crash. By changing the loading system, we did it more synchronously in order to have a better control on the memory load.
Also, there is a current issue with the system memory and the gpu memory. Once you loaded stuff in the system memory and transfert them to the gpu memory, you cannot freed them on the system memory. So, they are present at both places. One of my teammate is going to report that bug or that feature request soon.
Actually when you mark textures to not support get / set pixels, it will unload the texture in system memory.
the old devices though have a major difference in exactly this part of the handling:
3GS+ has 256mb unified ram, that can be used for anything from program data to textures. but memory that ends for gpu usage only won’t appear in allocation.
The first 2 generation of devices have 24MB VRAM at max, from which a good 2MB go into the framebuffers for front and backbuffer, leaves you with 22MB. Due to these textures must much more regularly be cached into RAM by the application where they actually hit the allocation.
@Dreamora
One issue is that there doesn’t seem to be a way to mark something as not Readable if it was downloaded via the WWW class. The notReadable flag is only supported for assets that are built into the project which is giving us issues. It is also not supported to be able to say call PackTextures and then flag it as no longer requiring get/set pixels after that initial construction.
This is causing issues as I’m using runtime spritesheets, and at around 16mb of VRAM worth of sheets I hit the cap in system memory on older devices(due to having all 16mb of no longer needed system memory used by textures sent to VRAM on top of all the assets required to build the next sheet).
Edit: I should probably clarify I am working with Matt_001, and that the explanation to the OP seems like it’s accurate.
To the OP: 4mb is the size of a 1024x1024 texture uncompressed. So as Dreamora said, it’s very likely that you are going over your VRAM limit and it’s caching one of your textures in RAM.
Guys, Thanks for the explanation. Actualy all my textures are not compressed. I don’t like the look of compressed texures as just about all of this particular game is 2D.
correct, stuff thats downloaded can’t be marked.
But even if you couldn’t it wouldn’t help. U3 at the time has a bug where such textures eat up to 10 times their actual amount of memory (reported that back on beta 3, sadly still not fixed - case 370039)
I had to backport an application earlier this year cause 12 WWW loaded 480x320 textures killed an iTouch 3GS application memory wise
Also the problem is there on any device. on 3GS+ you just don’t see it cause bombs on the VRAM side are not instrumented, you won’t see them till the system runs out of memory due to the VRAM taking over all memory
First of all, if someone is in beta - we significantly lowered memory needed for readable textures (and yes, i forgot about our plans to specify readable flag from code to lower it even more) - so try it out if you can.
Also for newer/older devices difference - see from where do these allocations come - gles drivers are implemented differently across ios verions/hw models. Gles allocations may end up as your app allocations for instruments in one case and not in another
@Alexey
That is good news. I’m hoping as well for the ability to use 16 bits/pixel textures as opposed to being forced to use 32 bits/pixel in downloaded textures to help reduce the memory needed even more. Just more places so I can get as many run time created textures as possible on the lowest end devices available.
Thanks for your time!