Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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?

share|improve this question
    
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) ;-). –  pad_ares 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
    
@pad_ares: FYI: You don't get to remove the duplicate notice on your question. If you don't agree, convince 5 others with re-opening powers to re-open it. Otherwise, live with it. –  Nicol Bolas Feb 5 '13 at 4:45
show 1 more comment

marked as duplicate by bummzack, Kylotan, Byte56, Trevor Powell, akled Feb 3 '13 at 21:53

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

3 Answers

up vote 5 down vote accepted

There are probably 2 main reasons:

  1. Creating MipMaps - when you want to create 4x smaller (area) image, you just divide width and height by 2 and compute the average of 2x2 pixels of big image into 1 pixel of small image. You can repeat it recursively. Thanks to PowerOfTwo size dimension the process is straight forward. E.g. mipmap 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)=111. pixel of bitmap. But if the width was power of two, e.g. 256, you can access (311&255)=56. pixel. "%" takes about 100 processor ticks (because of division), but "&" takes one tick. So with POT accessing textures is 100x faster.

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

share|improve this answer
    
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. –  pad_ares Feb 4 '13 at 22:39
add comment

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.

share|improve this answer
1  
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? –  pad_ares 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
add comment

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.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.