- February 19, 2011 at 9:47 am #30457
I’m relatively new to OpenGL and it’s taken me quite a while to figure out where the performance bottlenecks in it are. I thought I had them charted pretty good, until recently I read on a few places that *switching* textures is a slow operation on PowerVR hardware. Texture atlasses should alleviate the need for switches, but from reading the Apple OpenGLES performance guidelines and PowerVR’s “3D Application Development Recommendations” I don’t really see a recommendation to use texture atlasses to avoid *switching*. The suggestion to use texture atlasses is merely to reduce OpenGL calls, not explicitly about texture switches being extremely slow. Can anyone here at ImgTec shed some light on this matter?
Added: here’s an example of the type of information I find:
zmippie 2011-02-19 11:07:15February 22, 2011 at 11:09 am #34759
Hi zmippie,Using glBindTexture shouldn’t make any difference in performance besides what we’ve mentioned in our documentation, there is a small overhead but not a huge one. Some information out there seems to mention texture switching when using glTexture2D to reload textures which IS a slow call and should only be done when first initialising the app, for example as mentioned here: http://stackoverflow.com/questions/2682261/optimizing-texture-swapping-on-opengles-for-the-iphoneThis would generally be a slow operation on any device as the call loads texture data into graphics memory which is universally costly.However, as per our documentation, reducing gl calls is always a good idea, and so Texture Atlases can be useful in this respect. It can be much quicker to have textures packed into one texture atlas rather than switching between multiple, smaller textures. This is generally most useful when using sprites but can save time in all applications and may be worth adding to your apps, especially if you have many textures.Hope this answers your question? Thanks,Tobias
Tobias 2011-02-22 11:26:46February 22, 2011 at 11:49 am #34760
As Tobias says, the point here is that glBind calls to switch textures _are_ OpenGL calls and so should be avoided, if possible. The reason to use texture atlases is so that fewer (or none) of these texture bind calls need to be made between triangles and so it should be possible to render all sprites from an atlas in a single drawcall. At the extreme, a 2D game could render all its graphics with a single call.
In 3D games, models can use a texture atlas in order to draw all their parts in a single call or multiple models can share an atlas to avoid texture binds between drawing each of them (different wall sctions sharing a common brick texture, for instance).February 22, 2011 at 1:13 pm #34761
Okay, that’s really interesting info guys.Quote:using glTexture2D to reload textures which IS a slow call
I am aware of that, and I was indeed referring to glBindTexture (I should have mentioned that).
In theory, I would have sufficient texture space in a single 1024×1024 texture for all my sprites (in a single game level). But for most of the images, high quality is required (RGBA8888). For other parts, like for example, particles, I could easily use PVRTC4BPP, because the artifacts of that compression will not be easily discernible on the fast moving particles (and I have already determined that PVRTC2BPP and 4BPP are significantly faster to render).
So I guess I now have to determine what is the most efficient: a single “expensive” texture for everything, or multiple textures of which some can be “cheaper”.
I’m afraid that I already know the answer though: “test it”…
zmippie 2011-02-22 13:15:21February 22, 2011 at 3:31 pm #34762
Hi zmippie,Reducing the memory bandwidth is more useful than reducing gl calls, so in this case the best course of action would be to a texture atlas for each texture quality that you have. So whatever needs to be RGBA8888 could be in one atlas, and the PVRTC textures in another.Hope that was more helpful than “test it” 🙂Thanks,Tobias
Tobias 2011-02-24 10:06:45