Disadvantages of non power of two textures

[mbugala]

Hi,

From the docs Unity - Manual: Normal Map texture Import Settings window reference

NPOT Texture sizes generally take slightly more memory and might be slower for the GPU to sample, so it’s better for performance to use power of two sizes whenever you can. If the platform or GPU does not support NPOT Texture sizes, Unity scales and pads the Texture up to the next power of two size.

I’m interested in two things:

NPOT Texture sizes generally take slightly more memory

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.

NPOT Texture might be slower for the GPU to sample

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

[bgolus]

@mbugala

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.

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.

@mbugala

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

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

[DavidSWu]

I am not sure if this is still the

@bgolus

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.

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.

[soleron]

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.

[DavidSWu]

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

[fortgreeneVR]

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

NPOT Textures

I hadn't delved into the world of NPOT textures until yesterday, when I found out about how inconsistently they seem to be supported. When used on meshes, NPOT textures get converted (not sure exactly when this happens) to ARGB 32 bit textures, and resampled in the process. Strangely, they seem to be resampled using different gamma correction (or perhaps no gamma correction at all) than if you resize them on import. When used in GUITextures or in GUI(Layout) functions, they display correctly…

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)

[bgolus]

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.

[fortgreeneVR]

Yes, that makes perfect sense, thanks.