Disadvantages of non power of two textures

Hi,

From the docs https://docs.unity3d.com/Manual/ImportingTextures.html#TextureSizes:

I'm interested in two things:

1.

Why is that? I understand that some (old) GPUs don't support NPOT textures and Unity will upscale or pad them to POT. I understand that some GPUs might align NPOT textures with power of 2 positions in memory. But this doesn't seem like a general case. Is this memory footprint significant and where does it come from? I have done some basic tests with RenderDoc and couldn't confirm it.

2.

Why is that? Is it just integer arithmetic (with power of twos) vs float arithmetic (which is slower)?


It's hard to find some reliable (with an in depth explanation) information about NPOT textures, i would appreciate some light shed on it

 

The internals of GPUs when it comes to memory mapping is usually difficult to find hard information on. It's probably safe to assume any non-power of two texture is using a power of two worth of GPU RAM, but unless you're trying to absolutely maximize the GPU ram, I doubt this will really be an issue. Heck, Unity has a problem with projects that try to load more than 4GB of data at a time. Since most desktop GPUs have more RAM than that you're probably safe.

Nah. More just the fact that some older GPUs would fall back to software rendering if you asked it to use a NPOT texture (yes, really), or had to do extra math to remap the 0.0 to 1.0 uvs you passed in to the range the NPOT texture used within the POT memory space. Maybe special handling for wrapping, etc. Basically the requirement for supporting NPOT textures was added to Graphics APIs at a time when hardware didn't necessarily support it yet, so lots of GPUs had hack work arounds. As long as it didn't crash, it technically supported it. As recent as 3~4 years ago Intel integrated GPUs had performance issues with NPOT textures for similar reasons, and probably some low end mobile GPUs still do.

For all modern GPUs it's a non issue.

Basically that line from documentation was written 5 years ago and has only had minor updates since. Here it is from the Unity 5.0 documentation:
https://web.archive.org/web/20150703093823/http://docs.unity3d.com/Manual/class-TextureImporter.html

 

I am not sure if this is still the

We often use NPOT RenderTextures (i.e. the frame buffer). They do not seem to take up significantly more memory than would be expected based on their dimensions. They may be some rounding up to the nearest 8, 16, whatever, but 1280x720 does not become 2048x1024.
I think that this mostly applies to compressed textures and swizzled memory formats and only on some platforms.
RenderTextures have strange swizzling anyway.
They definitely don't support mipmaps in Unity which is clearly a no go for many applications.

 

Unless you are working on very limited hardware you should not worry that much. On the other hand, if your texture for whatever reason is a npot you may want to place it in a pot atlas texture along with others.

These things were a lot more important back when GPUs had 128MB memory

Today with 5-6GB vRAM this may not be as painful as it used to be. And again, this would be a problem if ALL your textures were npot. . And not if just a handful of textures out of hundreds is not.

 

I wish my phone had 6gb of VRAM.
(yes technically some high end ones might with unified memory architectures, but not many)

 

In this, admittedly old, post it is stated (by a Unity employee) that Unity will resize any NPOT texture to be POT and drop the compression if any
https://forum.unity.com/threads/npot-textures.54954/

Is that still the case and is that true for dynamically generated textures?
(I'm not considering render textures as they are a separate beast)

 

This is only for imported textures. Unity won't do anything to textures created via script, but if you try to make a non power of two texture and use a compressed texture format, it may fail to be created.

 

Yes, that makes perfect sense, thanks.