1
\$\begingroup\$

I read in this QA that NPOT will take memory as much as next POT sized texture. It means it doesn't give any benefit than POT texture with proper management. (maybe even worse because NPOT should be slower!)

Is this true? Does NPOT texture take and waste same memory like POT texture? I am considering NPOT texture for post-processing, so if it doesn't give memory space benefit, using of NPOT texture is meaningless to me.

Maybe answer can be different for each platforms. I am targeting mobile devices. Such as iPhone or Androids. Does NPOT texture takes same amount of memory on mobile GPUs?

\$\endgroup\$
1
  • 3
    \$\begingroup\$ I doubt the spec makes any mention of this, so it's implementation-specific. \$\endgroup\$ Jun 12, 2013 at 7:35

2 Answers 2

1
\$\begingroup\$

Render targets are one of the few areas where NPOT textures don't usually have problems, because it's very unusual for a screen resolution to be a power of two.

That other article is talking mainly about non-render-target textures. I also suspect the wasted space claim isn't entirely accurate - it will depend on how clever the driver is.

For post processing it's common to have render targets that are screen sized and half screen sized as another answer to that other question says. I'd be very surprised if that was different in performance from a POT sized render target.

The difference in render target memory usage between NPOT and POT is probably not worth worrying too much about. However, if you aren't making a screen sized one then a POT size might be a good choice (e.g. for shadow maps).

If you need to save memory I'd suggest looking at textures instead of render targets. There's lots of different formats available there with different quality vs size choices.

\$\endgroup\$
0
\$\begingroup\$

This is not a factual answer, just some speculations.

In older days (2005 or so) when you uploaded NPOT texture to memory you could see how much VRAM it takes (as much as next POT) and mipmapping was wrong because of border colors being sampled from padding areas.

If you Google you can see there are questions from recent years about XNA and iOS6 describing these issues are still existing.

From what I know the standard describes NPOT interface, but implementations (and flaws) are vendor-specific. The balance in question is between speed and usability. Implementing proper NPOT textures will make them much slower (sampling, scaling, tiling, mipmaps, VRAM allocation, etc).

Maybe you can make an experiment yourself and see the situation now.

\$\endgroup\$

You must log in to answer this question.

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