why would you use textures that are not a power of 2?

Question

In the early days of OpenGL and DirectX, it was required that textures were powers of two. This meant that interpolation of float values could be done very quickly using shifting and such.

Since OpenGL 2.0, and preceding that via an extension, non-power-of-two texture dimensions has been supported.

Are there performance advantages to sticking to power-of-two textures on modern integrated and discrete GPUs?

What advantages do non-power-of-two textures have, if any?

Are there large populations of desktop users who don't have cards that support non-power-of-two textures?

Answer 1

The reason that most systems (even many modern graphics cards) demand power-of-2 textures is mipmapping.

What is mipmapping?

Smaller versions of the image will be created in order to make the thing look correctly at a very small size. The image is divided by 2 over and over to make new images.

So, imagine a 256x128 image. This would have smaller versions created of dimensions 128x64, 64x32, 32x16, 16x8, 8x4, 4x2, 2x1, and 1x1.

If this image was 256x192, it would work fine until you got down to a size of 4x3. The next smaller image would be 2x1.5 which is obviously not a valid size. Some graphics hardware can deal with this, but many types cannot.

Some hardware also requires a square image but this isn't very common anymore.

Why do you need mipmapping?

Imagine that you have a picture that is VERY far away, so far away as to be only the size of 4 pixels. Now, when each pixel is drawn, a position on the image will be selected as the color for that pixel. So you end up with 4 pixels that may not be at all representative of the image as a whole.

Now, imagine that the picture is moving. Every time a new frame is drawn, a new pixel is selected. Because the image is SO far away, you are very likely to see very different colors for small changes in movement. This leads to very ugly flashing.

Lack of mipmapping causes problems for any size that is smaller than the texture size, but it is most pronounced when the image is drawn down to a very small number of pixels.

With mipmaps, the hardware will have access to 2x2 version of the texture, so each pixel on it will be the average color of that quadrant of the image. This eliminates the odd color flashing.

http://en.wikipedia.org/wiki/Mipmap

It's true that many modern GPUs can support non-power-of-two textures but it's also true that many cannot.

I had a 1024x768 texture in an XNA app I was working on, and it caused a crash upon game load on a laptop that was only about a year old. It worked fine on most machines though.

Also, when you have power of two integers, operations like addition, multiplication turn into bitwise shifts, which is much faster, even on current processors, though not that much noticeble.

Answer 2

One common use of non-power-of-two textures is for 'screen-sized' or 'half-screen-sized' (and so on) render target textures used for postprocessing effects.

In these cases, mipmaps aren't needed, the buffer is always uncompressed, so odd texture sizes cause less problems here

Answer 3

There were limitations for NPOT textures on older hardware. As mentioned on this OpenGL wiki, some older hardware requires NPOTs not to have mipmaps, compressed textures require alignment of 4x4 pixels, but new hardware should handle it perfectly.

In my experience, some even relatively new hardware experiences major performance hit if you use NPOT textures instead of POTs. I don't know what the issue is; it's possible that in some combination of render states, the rendering is actually done in software. So, unless you have good reasons, I'd recommend still trying to use POTs as much as possible.

As to why use NPOTs instead of POTs - if you have images that are of NPOT dimensions, say for example 1600x1200, using 2048x2048 pixel surface will waste a lot of video memory.

Answer 4

Are there performance advantages to sticking to power-of-two textures on modern integrated and discrete GPUs?

Most of modern GPUs support non-power of two (NPOT) textures and handle them well. Performance drop is quite little. But there are few problems to consider:

• When using NPOT texture it takes more space in RAM, just like next-sized POT texture. Technically you just waste the space that could be used to put something in there;

• NPOT textures may be handled noticeably slower (in OpenGL 2.1 I had up to 30% performance drop) compared to POT of next size;

• Older GPUs and on-board/on-chip GPUs are not so advanced, they often support NPOT textures, but support is quite slow and clumsy;

• Even older GPUs may refuse to accept/display NPOT textures at all;

• There could be edging artifacts caused by mip-map interpolation, your 25x25 texture might have a black fringe where pixels were added to stuff it to 32x32 size.

P.S. I don't know for sure about mobile devices, there might be even more restrictions regarding POT textures.

What advantages do non-power-of-two textures have, if any?

As far as I know there are only 2 advantages:

• They take less space on HDD if they are not packed (when packed empty areas give very little add)
• You can save time on writing NPOT -> POT converter. You will need one for release version, but using NPOT textures for designing and prototyping interface / models is just fine

Are there large populations of desktop users who don't have cards that support non-power-of-two textures?

As far as I know and tested on PC - Yes. That includes major percentage of speed-drop / minor bugs GPUs and minor percentage of cards that won't handle NPOT at all.

Answer 5

My programmer art is only of the correct size.

It certainly simplifies my display logic to know that if I want to set a texture to the top left of the screen that I can just set 0,0 as the top left of the texture and see all the texture there in the correct location, whereas if I had to add 0alpha padding, positioning the texture against the edge of the screen would be more complex. Plus, of course, that 0alpha still has to be alpha blended, and if I'm looking at opaque textures, I may prefer not to have an alpha channel.