Can you explain me, why hardware acceleration required for a long time textures be power of two? For PCs, since GeForce 6 we achieved npot textures with no-mips and simplified filtering. OpenGL ES 2.0 also supports npot textures without mipmaps and etc. What is the hardware restriction for this? Just simplified arithmetics?
+2
A:
I imagine it has to do with being able to use bitwise shift-left operations, rather than multiplication to convert an (x, y) coordinate to a memory offset from the start of the texture. So yes, simplified arithmetics, from a processor point of view.
Thorarin
2009-11-16 08:59:32
But hardware may have additinal buffer associated with texture: array of pointers to lines. And access would be as fast as two dereferences. These all suggestions are from traditinal CPU point of view. This may not be true for GPU. For example, branching for x86 is very lightweight, but very slow for GPU! In another words, I want to say that texture addressing may differs from CPU addressing. For example, I heard that GPU caches by blocks (for ex 32x32 pixels) and not the lines as CPU do. And finally, I think two derefs is pretty fast.
demi
2009-11-16 09:12:18
Two derefs take twice as long as one deref, so that makes it take 2x as long...
Chris Dodd
2009-11-17 00:31:00
+1
A:
I'm guessing that it was to make mipmap generation easier, because it allows you to just average 2x2 pixels into one pixel all the way from NxN down to 1x1.
Now that doesn't matter if you're not using mipmapping, but it's easier to have just one rule, and I think that mipmapping was the more common use case.
Incredulous Monk
2009-11-17 00:22:12