Why use textures that are Power of Two? [duplicate]

Possible Duplicate:
Why are textures always square powers of two? What if they aren’t?

I am using C# and XNA (also MonoGame for other platforms than Windows) to create a game in 2D. Ususally for all textures I use the NVidia plugin for Photoshop to create DDS files with precomputed mip-maps (either full color, or DXT-5).

How important is it, nowadays, to stick to textures with extensions that are a power of two? What are the advantages and disadvantages of doing so?

The background of my question for that I use a number of quite large background images in with 1980 x 1080 pixels in size and storing them in textures of 2048 x 2048 pixels size seems like a tremendous waste of memory.

Let me stress that I am aware that having only power-of-two textures has been important in the past for certain specific optimizations BUT I would like to know whether this TODAY (GPUs of the last ~2 years, current consoles etc.) is still required?

• Although I agree that this is mostly a duplicate, I guess the issue of "how relevant is it today?" could do with more attention. – Kylotan Feb 3 '13 at 13:25
• Exactly, there is no need for an explanation of why it was important at some point (except it still is) ;-). – ares_games Feb 3 '13 at 13:33
• Note that XNA's power-of-two texture support is listed in this table. – Andrew Russell Feb 3 '13 at 15:21
• Generally speaking though, if you're using a 3rd party tech, such as XNA, whether you need PoT textures is decided by the tech. The writers of that tech will have made their own decisions about the tradeoffs. – Kylotan Feb 3 '13 at 15:36
• @Nicol: Sorry, I did not know that. I understood the notice as a request to edit my question to make it more clear and underline the difference to the other somewhat similar question. However, you deleted that explanation. So I leave it like that to avoid further downvoting. – ares_games Feb 5 '13 at 12:19

There are probably 2 main reasons:

1. Creating MipMaps - when you want to create an image with 2x smaller resolution, you just divide the width and the height by two and compute the average of 2x2 pixels of a big image into 1 pixel of a small image. Thanks to PowerOfTwo, the process can be repeated until some dimension reaches 1. E.g. sizes 512x128, 256x64, 128x32, 64x16, 32x8, 16x4, 8x2, 4x1. Try to do that without POT at the beginning.
2. Repeating textures - let's say your texture is 200px wide and you want to get the pixel at x=311. To get your pixel, you should access the (311%200)=111th pixel of bitmap. But if the width was POT, e.g. 256, you can access (311&255)=56th pixel. Computing "%" is about 100x slower than "&" (because of division). So with POT, accessing textures is 100x faster.

These reasons are purely mathematical and no hardware or software improvement can change that.

• I was wondering whether modern graphics hardware does not store mipmapped-textures in POT-textures automatically such that I as used do not have to deal with that. – ares_games Feb 4 '13 at 22:39

Are we talking mobile GPUs or desktop?

Desktop GPUs (that is the HiDef profile in XNA) will handle non-power-of-two textures just fine - with maybe a bit of performance degradation in some cases (same as those listed below). See Ivan Kuckir's answer for additional details.

Some older and Mobile GPUs (or the software for them; Reach profile in XNA) emulate non-power-of-two support by bumping the internal texture size up to the next power-of-two. This extra border of "undefined" data around the texture means that mipmaps, wrapping and DXT compression are impossible (instead of simply being slow). It also wastes memory for you.

In your case, using a non-power-of-two texture is not a problem, providing you do not use those three features on the Reach profile. For such large backgrounds, the inability to use DXT compression is painful. But if you're targeting HiDef, by all means use it, even with non-power-of-two textures - it's almost certainly worth it.

• Why wouldn't DXT compression work on non-pow2 textures? It uses 4x4 blocks, so it ought to work fine on any image whose dimensions are multiples of 4. And even if they're not multiples of 4, most DXT encoders support partial blocks - where only a subset of pixels in the block are considered important for the fitting process. – Nathan Reed Feb 3 '13 at 17:14
• It does work, as you say, with partial blocks. It doesn't work for an "emulated" non-power-of-two texture because there is no support for partial blocks, and the full blocks at the boundary would get data from undefined regions of the image. (Obviously if the dimensions are a multiple of 4 it could work - but this would still require a special case to handle it, that isn't available in the Reach profile.) – Andrew Russell Feb 4 '13 at 3:20
• DXT definetely works also for non-POT textures. Also, I am targeting desktop systems (HiDef profile in XNA) so technically I could use non-POT textures. However, should I? – ares_games Feb 4 '13 at 22:40
• @pad_ares Come to think of it - I'd speculate that DXT would gain you more than enough performance to make up for any potential performance loss caused by using it on a non-POT texture. (Obviously this is both speculation and performance advice - so measure it if you need to know for sure.) There is no big, scary reason not to use non-POT textures if you need them. (Also I'll clarify my answer a bit.) – Andrew Russell Feb 5 '13 at 8:39

In the end you're dealing with fitting little blocks of memory into a big block of memory, some underlying hardware constraints, time/space sensitive compression to match, and a requirement for maximal usage with minimal fragmentation over a random duty cycle.

Solution = pow2 sizes to make blocks fit together more easily, to align with a variety of underlying hardware, and to allow for optimized block compression that may or may not reside in hardware.