0
\$\begingroup\$

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?

\$\endgroup\$
6
  • \$\begingroup\$ Although I agree that this is mostly a duplicate, I guess the issue of "how relevant is it today?" could do with more attention. \$\endgroup\$
    – Kylotan
    Commented Feb 3, 2013 at 13:25
  • \$\begingroup\$ Exactly, there is no need for an explanation of why it was important at some point (except it still is) ;-). \$\endgroup\$
    – ares_games
    Commented Feb 3, 2013 at 13:33
  • \$\begingroup\$ Note that XNA's power-of-two texture support is listed in this table. \$\endgroup\$
    – Andrew Russell
    Commented Feb 3, 2013 at 15:21
  • \$\begingroup\$ 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. \$\endgroup\$
    – Kylotan
    Commented Feb 3, 2013 at 15:36
  • 1
    \$\begingroup\$ @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. \$\endgroup\$
    – ares_games
    Commented Feb 5, 2013 at 12:19

3 Answers 3

Reset to default
8
\$\begingroup\$

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.

\$\endgroup\$
1
  • \$\begingroup\$ 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. \$\endgroup\$
    – ares_games
    Commented Feb 4, 2013 at 22:39
2
\$\begingroup\$

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.

\$\endgroup\$
4
  • 2
    \$\begingroup\$ 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. \$\endgroup\$
    – Nathan Reed
    Commented Feb 3, 2013 at 17:14
  • \$\begingroup\$ 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.) \$\endgroup\$
    – Andrew Russell
    Commented Feb 4, 2013 at 3:20
  • \$\begingroup\$ 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? \$\endgroup\$
    – ares_games
    Commented Feb 4, 2013 at 22:40
  • \$\begingroup\$ @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.) \$\endgroup\$
    – Andrew Russell
    Commented Feb 5, 2013 at 8:39
1
\$\begingroup\$

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.

\$\endgroup\$

Not the answer you're looking for? Browse other questions tagged .