pouët.net

I've just noticed (rather late I must confess) that these days you can have textures with any size rather than 2^n. They seem to behave exactly like 2^n textures (0->1 uv coordinates). But I wonder if there is a speed penalty for using them. What do you think ?

as a side question, why would you need them ? to have render to texture match the screen resolution ?
i doubt it makes much difference to have mesh textures not being 2^n but am i right to make this assumption?

There are plenty of (non-demo) cases where I would need them to be non power of 2.

I don't think it makes much of a difference on current hardware.. I never noticed differences. But then again, I never really did a comparison.

on most hardware, they perform worse than normal textures under rotation and or zooming.

so they are save to use for screen-space stuff (glare etc.), but i would hesitate to use them when i expect rotation / minification / mipmapping.

There used to be a speed penalty on older GPUs (for obvious reasons) and, at least on hardware level (Xbox for ex.) it would expect non-normalized (e.g [0-640][0-480]) UVs -- but I guess D3D or OGL has the driver solve this for you these days.

A common use is, indeed, for UI graphics 'n stuff. Especially if you have fixed res. (e.g console display 720p) it can make sense.

chaos has it more dead on as usual :)

Be careful if you use them. I know that lots of ATI OpenGL implementation lets you use non power of two textures and the driver silently falls back into software-rendering if you do anything but simple blits with them.

Happens on cheap ATI cards as used in office computers.

Navis: size is not important, the important thing is how you use it.

opengl for 2d graphics...

I have seen a diagonal artifact when using npot textures+bilinear filtering, where the texels correspond to pixels and where the texture is clipped to the window rect.

Using pot textures and the artifact goes away. I have filed a bug report to apple.

heh you are still thinking about zoom rotators aren't you ;).

The only problems with npot textures is that mipmaps may take more memory than they should (it depends on implementation). Another problem is with DXT compression - I round to even both width and height. As for the performance - I really didn't found a case when it was a serious bottleneck. On the other hand it saves some work to artists and they will not mumble you about upscaling/downscaling artifacts.

just draw a giant triangle and align topleft, problem gone as well :) this is just caused by draw/sampler hardware implementation.

bonzaj: mipmaps for npow2 textures? never really used them (for reasons such as chaos mentioned). dxt'ing non pow2 textures it not an often seen usage pattern either (slight overhead no problem).



hihi :)

Size matters, click here to enlarge your <insert anything you talk about>

I encountered the problem torus described too. When it comes to OpenGL this is bad, because it is reported/expected to be supported in hardware, but it isn't and you have no way of detecting that... sucks.

There's no good reason for NPOT-textures to perform worse than POT-textures. What Chaos describes sounds like the lack of texture-interleaving that earlier GPUs had for these textures - I don't think this is the case any more (at least I know very well of some GPUs where it isn't :P). To be able to effectively interleave textures, the pitch must be dividable by some small POT value (8, 16, 32). Luckily, the driver has the ability to choose the right pitch.

In fact, if you need to up-scale or pad an image to make it fit in a POT-texture, you're loosing some performance compared to NPOT-textures.

so is it safe to say that modern cards (nvidia series 9 and those 260 280) as well as ati are safe ? or are ati prone to fail

ati prone to fail for sure.

I'm using NPOT textures in OpenGL since 2005 (for screen space effects mostly) and they seem to work very well, no problem at all. Navis, it's safe to do it evne in my (now 5 years old) AGP Radeon9800. I think it was ATI who implemented them first, nvidia waited for the 6 series afair.

For regular material textures I don't know. I guess it must be a nightmare to do mipmapping in a 1021 x 719 texture for example...?

Non-Power-Of-Two-Textures are internally nothing else than a 2^(n+1)-Texture with the rest of each scanline left blank.
Of course a 2^n texture is smaller and thus performs better.

lazy-san: nope.

lazy-scan, are you sure of that?

Navis, I forgot about one practical restriction we found here at work with npots: in nVidia hardware don't work correctly if texture resolution is not a multiple of 4.

gf3 gpu could do it just fine as well. but, as kusma described, without the interleaving and just pure linear mem layout (hence 'linear textures' moniker back then).

In '1995' some ATI cards crashed when our 3D texture depth wasn't a power of two so we had to insert empty textures to make it so. IIRC we've had some problems with npot 2d textures when used with glsl (ATI of course). With screen space effects (framebuffers) we've had no problems.

iq: non-power-of-2 textures are not just subregions of power of 2 textures, no. if you load a non-pow2 texture with d3dx's load texture functions x it can however extend it to be a power of 2.
if you generate mipmaps for them, the next mip level down is extended to pow2, if i recall correctly.
dxt is only possible if the dimensions are multiples of 4.

there's something about extra padding when using non-pow2 mipmaps as well afair. but that's driver/hw level.