I'm loading a lot of textures as part of my app. I load them on a "load-thread" and use them on my main thread using another GL context and the 'shareContext' mechanism. I'm using the OpenGL ES instrument to see what's going on and it is reporting that over 2x the number of textures I've actually allocated are resident. In other words, the load thread loads about 37 textures as part of my startup but the profiler is showing 83 textures as resident (in the "resource count" list). I'm also consuming about 5.8M with my textures, but Instruments is reporting 11.9M. I am seeing the numbers go down when I delete textures later in the process so I assume that instruments recognizes memory freed by glDeleteTextures.
I want to chalk this up to a bug in the Instrument that is counting textures, say, 2.24x for each one, but that would be an odd bug to say the least. I suspect that if I could strip the extra GL context, that I'd find it was the culprit... but that won't be easy so I'm hoping that someone can confirm seeing this or something else that looks like this.
Note that this is all performance testing on a 1g iPod. I can not use the new GL profiler since it requires a 3g or better.