NPOT Texture allocation bug « cocos2d for iPhone

cocos2d for iPhone » Programming » cocos2d internals

NPOT Texture allocation bug

(90 posts) (18 voices)

Started 1 year ago by riq
Latest reply from goodeats2009

Tags:

12 3 Next »

riq
Key Master
A few weeks ago I recommended to use NPOT (Non Power Of Two) textures due to a bug on iOS that was allocating 33% more memory for POT textures.

But these past days I have been doing more research on this an apparently iOS is allocating up to 99% more memory for NPOT textures.

These are the tests that I did:
```
2048x2048 + RGBA texture:  21.34 Mb  (instead of 16Mb... 33% POT mipmap bug).
2047x2047 + RGBA texture:  31.99 Mb ( instead of 16Mb. 99% more )
1025x1025 + RGBA texture:  7.26 Mb   ( instead of 4Mb. 81% more )
1536x1536 + RGBA texture:  15.75 Mb (instead of 9 Mb. 75% more )
```
I measured everything with Instruments + VM Tracker and paying attention to the dirty memory.

Before recommending everybody to stay away of NPOT textures, I would appreciate if you could do some tests with your game and confirm whether or not this is a bug.

How to test it:

1. Run your game with Instruments + Allocations
2. Once Instruments is running, switch to VM Tracker
3. Once one of your NPOT textures is loaded/displayed, take an snapshot and see the "Dirty" memory.

Repeat the same exact steps but using POT textures instead.

Please, report on this thread the "dirty" values both for POT and NPOT textures.

If you are using cocos2d v2.0, then NPOT textures are enabled by default.
If you are using cocos2d v1.0, then you have to enable NPOT textures on the ccConfig.h file:
```
#define CC_TEXTURE_NPOT_SUPPORT 1   // <-- enable NPOT for cocos2d v1.x
```
Thanks.

PS:
I opened a post at the Apple forum:
https://devforums.apple.com/thread/147591
Posted 1 year ago #
QcMat
Member

Thanks for letting us know, this news is at a very very good time for me to investigate, as we just submitted and can pull. I'll try to do those tests tomorrow first thing.

Posted 1 year ago #
alchemygames
Member

In our current game, with cocosd2 v1.0.1, we where hitting several memory warnings with the iPad 1, and after enabling NPOT texture support they where gone. So in the iPad 1 it was allocating less memory for sure.

In the rest of devices there were no probles, so no further test where done.

Posted 1 year ago #
riq
Key Master

@alchemygames:
Interesting. Which iOS version were you using on your iPad 1 ? What technique did you use to measure the memory? Thanks.

Posted 1 year ago #

frilla
Member

Here are the results for a .pvr.ccz file using RGBA8888. I'm not sure exactly what value you wanted (which type, which column) so here are the deltas after loading the spritesheet:

2048x2048:
Type     Resident Size     Dirty Size
*All*     +21MB               +16MB
*Dirty*  +21MB               +16MB
*IOKit*  +21MB               +16MB

2047x2047:
Type     Resident Size     Dirty Size
*All*     +16MB               +16MB
*Dirty*  +16MB               +16MB
*IOKit*  +16MB               +16MB

on iOS 5.1 with cocos2d 1.0.1 on iPhone 4S

Posted 1 year ago #

rickms
Member
Riq, I've done some tests on and was unable to confirm your findings. Is it possible this is an OpenGL 2.0 only issue?

First Test (Ran 3 times)
```
iPhone 4 / iOS 5.1 / Cocos2d 1.1b
  1024x2047 RGBA - Expected texture size ~8MB

Dirty memory:  ~37MB.
 I dug deeper into the details and found a corresponding IOKit allocation of exactly 8MB
```
Second Test (Ran 3 times)
```
iPhone 4 / iOS 5.1 / Cocos2d 1.1b
  1024x2048 RGBA - Expected texture size ~8MB

Dirty memory:  ~40MB.
The 8MB Allocation in the first test was replaced by a 10.64MB allocation.
```
The increase of the 8MB allocation by ~33% to 10.63 accounts for the entire memory discrepancy.

I repeated these tests on an iPad 1 with IOS 4.3 and got similar results.

EDIT:

Riq, do you have a test project that duplicates this? I'd love to compare results.
Posted 1 year ago #
riq
Key Master

@frilla:
I am a bit confused by your numbers since "dirty" is 16MB both on POT and NPOT. very strange...

In order to make sure that we are talking about the same "dirty" size, number, this is the one that I need. Thanks!

Posted 1 year ago #
riq
Key Master

@rickms:
Thanks for your feedback. Apparently it seems to be an OpenGL v2.0 bug, or a cocos2d v2.0 bug, or my tests are completely flawed.
Yes, I do have a test project here:
https://github.com/ricardoquesada/test-ios-npot-texture-memory

Posted 1 year ago #
rickms
Member

@riq

Hmm odd there seems to be an extra malloc of the same size of the texture by gfxAllocateTextureLevel, but it seems to only happen for NPOT textures. Looking more and more like an implementation bug/'feature'.

Posted 1 year ago #
frilla
Member

@riq:
The numbers I posted includes the one you circle in red.

I checked the code, CC_TEXTURE_NPOT_SUPPORT is not taken into consideration when loading .pvr.ccz, could this be a reason for the results?

Posted 1 year ago #
rickms
Member

And just another follow-up, to confirm @riq that gfxAllocateTextureLevel is being called by glTexImage2D for NPOT textures only.

Posted 1 year ago #
riq
Key Master

@frilla: Yes, PVR images are not affected by the CC_TEXTURE_NPOT_SUPPORT. What is strange is that your "dirty" value is similar for POT and NPOT.

@rickms: Thanks. Which cocos2d version were you using for your tests ? Are you still on v1.0 or did you test it with my test project ?

Thanks.

Posted 1 year ago #
frilla
Member

So after testing again a few times, I can't even reproduce +21MB in resident memory when loading POT texture of my earlier post. Right now, the results after many tries are the same wether the file is POT or NPOT for my .pvr.ccz RBA8888.

I also checked the "real memory" value in Activity Monitor instrument and this value never increments more than 16MB when loading the file, POT or NPOT. So right now, I'm wondering if I'm affected by this 33% bug at all. Am I suppose to be affected by this bug if I'm using .pvr.ccz?

For the testing, I check the values in Instruments, then load the file when a button is pushed using [[CCSpriteFrameCache sharedSpriteFrameCache] addSpriteFramesWithFile:@"myFileName.plist"]; and then check the values in Instruments again. Is my method flawed?

Posted 1 year ago #
riq
Key Master

@frilla: I am not sure if CCSpriteFrameCache loads the texture into memory or not. In order to be sure, could you also create an sprite and add it to the scene ?
Thanks.

Posted 1 year ago #
rickms
Member

@riq that was using your test project, shows up in the VM Tracker and under allocations.

Posted 1 year ago #
riq
Key Master

@rickms: thanks. So you were using cocos2d v2.0. I will do the same test, but with cocos2d v1.0 to see what happens.

Posted 1 year ago #
rickms
Member

@riq I tested the 1.1 tree originally and the only memory difference was the allocated mipmap memory for POT textures so I think it's pretty safe to say it's a GL2.0 implementation issue. Interested to see what else you find.

Posted 1 year ago #

riq
Key Master

Same tests using cocos2d v1.0 (OpenGL ES 1.1):
https://github.com/ricardoquesada/test-ios-npot-texture-memory/tree/cocos2d-v1.0

PVR 2048x2048 + RGBA:  21.34 Mb  (instead of 16Mb... 33% POT mipmap bug).
PVR 2047x2047 + RGBA:  31.99 Mb ( instead of 16Mb. 99% more )
PNG 2047x2047 + RGBA: ~16.00 Mb (expected value)
PNG 1025x1025 + RGBA:  ~4.00 Mb   (expected value)
PNG 1536x1536 + RGBA:  9.00 Mb (expected value)

Mmm... why the PVR are generating more memory ? This seems to be a cocos2d bug

Posted 1 year ago #

riq
Key Master

With cocos2d v2.0 and using PNG instead of PVR:

2047x2047 + RGBA texture:  ~24 Mb ( instead of 16Mb. 50% more )
1025x1025 + RGBA texture:  7.26 Mb   ( instead of 4Mb. 81% more )
1536x1536 + RGBA texture:  16 Mb (instead of 9 Mb. 75% more )

Mmm... I will try to use GLKit...

Posted 1 year ago #

riq
Key Master
Using GLKit + cocos2d v2.0:
```
2047x2047 + RGBA texture:  16 Mb ( OK )
1536x1536 + RGBA texture:  9 Mb ( OK)
1025x1025 + RGBA texture:  4 Mb   ( OK )
```
So, it seems to be a cocos2d bug (or cocos2d is triggering a bug on iOS).
If I can't find the bug I will add a "If iOS > 5.0, then use GLKit texture loader"

GLKit tests are here: https://github.com/ricardoquesada/test-ios-npot-texture-memory/tree/glkit
Posted 1 year ago #
riq
Key Master

Update:
The PVR loading is fixed by moving the glTexParameters before loading the texture.

I still need to figure out how to fix this for PNG images.

UPDATE2:
PNG is working OK too.

So, there are two iOS bugs here:
- BUG #1 If you set the glTexParams after creating the texture, then it will allocate more memory. I did know that calling glTexParams after creating the texture was slower. But the bug is that it is allocating more memory.
- BUG #2: NPOT RGB888 textures (which should be avoided in the 1st place) allocates 100% more memory. Apparently when the texture is expanded internally for 32-bits, it allocates extra memory and is not released until the texture is unloaded.

Posted 1 year ago #
cybergreg
Member

@riq - thanks for your (continued) amazing work... :-D

Posted 1 year ago #
frilla
Member
@riq: So I created a sprite with the pvr.ccz instead of loading the plist file and got similar numbers as yours.
```
2048x2048: dirty size +21MB
2047x2047: dirty size +32MB
```
I did play with glTexParameteri in CCTexture2D#setTexParameters (comment or moving them) and the dirty size increase was then 16MB (POT & NPOT) file but with visual bugs. I guess I'll wait for the official fix.
Posted 1 year ago #
alchemygames
Member

@riq: The iPad is running iOS 5.0.1.

However, we didn't do any formal test, but without NPOT texture support the game was hitting so many memory warnings it eventually crashed, and with NPOT textures enabled, with the exact same code, no memory warning was triggered.

Posted 1 year ago #
rickms
Member

@riq nice work. My tests on 1.1 were indeed PNG only which is why I didn't notice the PVR difference.

Posted 1 year ago #
riq
Key Master

I have just added some tests into cocos2d (see Texture2dtests.m)... apparently I didn't fix the bug correctly... I am still working on it.

Posted 1 year ago #
riq
Key Master

argh... apparently the combination of NPOT + 16-bit textures is completely broken on iOS 5

Posted 1 year ago #
rickms
Member

@riq it's probably not worth too much of your time if it's an iOS thing... The overhead of the POT mipmap bug on 16 bit textures isn't as big a memory waste as it is w/ 32 bit textures. Probably should throw up a matrix somewhere of memory usage w/ the various pixel formats vs POT/NPOT.

Posted 1 year ago #
riq
Key Master

@rickms: Yes, thanks. I am doing a matrix that shows the different allocations for the different formats, sizes.

Posted 1 year ago #
riq
Key Master

I will document my findings here in this matrix:
http://www.cocos2d-iphone.org/wiki/doku.php/prog_guide:textures

What is driving me crazy is that yesterday GLKit and non-GLKit was working OK (or at least I believed so), but not today.

Posted 1 year ago #

RSS feed for this topic

12 3 Next »

Reply »

You must log in to post.