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.

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?

share|improve this question
    
See this excellent answer to a similar question: Why do images for textures on the iPhone need to have power-of-two dimensions? –  Dvole Jan 31 '11 at 19:56

4 Answers 4

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

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
3  
If you're using texture formats that are compressed in memory (PVR or DXT, for example), scaling up to the next power of two is going to use significantly less texture memory than a uncompressed, but smaller, NPOT texture. –  Tetrad Jan 31 '11 at 21:16
3  
Your wording is a little vague, so sorry if this is redundant with what you're trying to say - compressed textures still require pixel sizes in multiples of 4, even on modern hardware that supports NPOT textures. –  user744 Jan 31 '11 at 21:21
1  
I would expect current hardware to still be tiling/swizzling textures in the drivers when you upload them. This changes the layout of the texture to make accessing more optimal for the hardware. Consoles (I'm not including XNA in that) require you to manually perform this layout optimisation in your own tool chain, I'm pretty sure these only work on POW2. –  Roger Perkins Jan 31 '11 at 23:00

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.

share|improve this answer
5  
Usually one positions polygons, not textures, on-screen. The polygons can be given whatever UVs are necessary - they don't necessarily need to go from 0 to 1; if your texture is only 30 wide, it's fine to go to 0.9375 (which is another reason POT textures are good - UVs are exactly representable). –  user744 Feb 1 '11 at 0:42

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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