Texture Sizes in Video Ram

[Jamie W]

Hello,

Just a quickie;

Textures in Video Ram, are ideally to a power of 2 (128,256,512 etc) for width, but does this also apply to height?

So for example, a 512 wide * 130 high texture isn't wasteful on resources?

[Bad Sector]

Both must be powers of two, for optimized access. In some cases, this:

texel_offset = (texel_v << o) + texel_u

is fast, but in others

texel_offset = (texel_u << o) + texel_v

is faster. Depends on the driver, implementation, etc. Note that the above are optimizations of:

texel_offset = texel_v*texture_width + texel_u

where o, is a power of 2, such that "2 << o == texture_width".

To make these optimizations possible, some restrictions have to be placed.

But newer cards support rectangular textures which can be of any size. But they're considerably slower.

[Jamie W]

Yeah, I can understand the logic / reason for the power of 2 on the width of the texture; I just don't understand why it should be needed on the height also...

[Bad Sector]

my fault on the second snippet: the o there is "2 << o == texture_height" :-).

It may be faster to access texel data this way for some implementations.

[zoombapup]

Jamie, I'm only guessing, but it may have something to do with the addressing modes of the video card. Clearly if you use power of two textures, your addressing calculations become much simpler to compute (next offset from one 256x256 texture to another is faster to compute than ??x256 OR
256x?? if that makes any sense.

Basically, its like a form of granularity, much like data access is faster if it is aligned at a certain granularity (page, word, whatever).

[Jamie W]

Jamie, I'm only guessing, but it may have something to do with the addressing modes of the video card. Clearly if you use power of two textures, your addressing calculations become much simpler to compute (next offset from one 256x256 texture to another is faster to compute than ??x256 OR
256x?? if that makes any sense.

Basically, its like a form of granularity, much like data access is faster if it is aligned at a certain granularity (page, word, whatever).

Hi Phil,

Yeah, and it makes perfect sense; it's going to be way faster to compute pixel addresses if the texture width is a power of 2.

The only reason I can see for having the texture height to be a power of 2, is for when the texture 'wraps around'. So you'd just need to mask the y postion with (height-1, e.g. 255) assuming height is a power of 2.

Guess I just want clarification really, on the texture height being a power of 2.

[Bad Sector]

The only reason I can see for having the texture height to be a power of 2, is for when the texture 'wraps around'. So you'd just need to mask the y postion with (height-1, e.g. 255) assuming height is a power of 2.

Actually you've given yourself a very good reason. Just see how many times are repeated.

[Pogacha]

Also some old video cards requieres textures to be squared.

[Brian A. Knudsen]

64x128 is fine also in old gfxcards afaik. nomatter what, remmber you have alphablending to remove 'the squarish' look and also all gfxcards have texture compression anyways.

[oNyx]

Also some old video cards requieres textures to be squared.

First time I heard that. Even a Voodoo 1 is fine with rectangular textures.

[Donavon Keithley]

Yes it applies to height, because whenever possible, textures are not stored in memory linearly, scanline by scanline. Why not? Because fetching texels from RAM is slow, and therefore a cache is used to hide the latencies.

Consider a 2D sprite. A linear texture will have optimal cache performance only if the sprite isn't rotated (or rotated 180 degrees). Adjacent texels will usually live next to one another in the same cache line.

But consider if it's rotated +-90 degrees. Each texel could end up consuming an entire cache line -- worst-case performance. (That's not quite true because rasterization doesn't generally go scanline-by-scanline either -- but we'll ignore that.)

So whenever possible, textures are "swizzled" -- rearranged into m x n blocks -- giving considerably better performance in the general case.

Using a non-pow2 width or height is likely to force the texture into linear addressing, or the driver might allocate the next higher power of 2 or work around hardware constraints some other way. You can probably imagine why non-pow2 textures often have limitations like no wrapping.

It's not as significant an issue with modern hardware, but the further back you go the more non-pow2 hurts.

[Pogacha]

First time I heard that. Even a Voodoo 1 is fine with rectangular textures.

Voodoo 1 wasn't the first card. Before AGP appeared there were lots of graphics cards .

64x64 is the only safe size. But usually those old cards have lots of problems about direct3d driver implementation as lack of blending and the famous clipping problem.

You can go for [64,128,256]x[64,128,256] as safe values to trace a line and go for no drivers problems cards as Voodoo 1, Savage Pro and so.

In the device description of the D3D it is specified the max aspect ratio the texture can have.

[oNyx]

Yea, the Voodoo1 certainly wasn't the first graphics card, but its the lowest of the low (together with Intel integrated ) if you go for acceleration. Its a PCI add on card btw, which didn't offer the basic 2D stuff. Its a card bought by hardcore players who have most likely upgraded their rig since then. And if they didn't... does your game run on a Pentium 200 or a Celeron 333? If not there is nothing to care about. (Those who upgraded the CPU to something slightly better like a 500mhz CPU are only a tiny fraction of another tiny fraction.)

The Voodoo2 was basically the same. The Banshee (Voodoo 2.5 if you like) was the first Voodoo card with integrated 2D stuff and it was also available for AGP.

Well, even the Banshee is a bit too old. It was released at the end of 1998... so its soon about 8 years old. And hardware is built to last about 6 years. The Banshee over in my ultra crap test machine died a few weeks ago and was replaced with a GeForce2MX (classic one, its like a 400), which is also already about 6 years olds.

>64x64 is the only safe size.

Yea, thats the absolute minimum an implementation has to support accordingly to the OpenGL specs. Fortunately the lowest one you've to consider is 256x256. (I go for 512x512 with downsampling fallback.)

What I mean is that you have to draw the line somewhere. If you do, make sure it makes sense. Making it run on a Voodoo 1-3 isn't worth it if the game requires 1ghz etc.

[Pogacha]

Yes, I completely agree.
And yes, squared textures are only anecdotal at this point.

[lapskaus]

OpenGL certainly did not like drawing a 1024x768 image fullscreen. The speed dropped down to several SPF (seconds per frame), and all the app was doing was draw that image. I added a black bar on the bottom and resized it to 1024x1024, and it was running super fast again. (like 200 FPS)

[zoombapup]

Just a quick point, If I recall after a lot of years. I believe OGL's spec actually allowed 32x32 textures but I had a load of problems with textures not showing up properly below 64x64. So I'd definitely go for minimum 64 in any dimension.

[niX_BB]

The windows GDI and DirectDraw allows one to specify textures of any dimension, but GL and D3D require power of two - I always assumed the difference was for the sake of mip-map generation. I never considered any of the speed optimizations suggested above.

Just goes to show that a fresh perspective on your age old assumptions is never a bad thing.

[TJM]

Does D3DX_FILTER_NONE eliminate the need for the power of 2?

[dxgame]

Bottom line, use 512x512 textures for the most compatibility with today's cards. Use 256x256 textures if you want it to run on pretty much any gpu the last 5 years or so. I personally use 1024x1024 textures for everything now days, throw as many sprites/tiles on each texture, use as FEW textures as possible and go with it. Works great! (DX8)

[Pogacha]

Does D3DX_FILTER_NONE eliminate the need for the power of 2?

No way!
"Rectangular" non power of two textures is an additional hardware feature of some cards only.

[TJM]

According to information I find, it appears if the video card does not support non-power of two textures, then D3DX_FILTER_NONE can be used (which will cause pixels in the destination region that lie outside the source region to be replaced with transparent black). With this value, no scaling will be performed.

Even though it is easier to use power of two textures, it appears that it can be worked around if a programmer prefers.

Here are some articles that I read that seem to support this:

http://www.gamedev.net/reference/art...rticle1972.asp

http://www.xmission.com/~legalize/bo...plications.pdf

http://www.xmission.com/~legalize/bo...%20Library.pdf

http://www.xmission.com/~legalize/bo...0Texturing.pdf

Here is a quote from one of the articles:

"The easiest way to deal with the constraints is to create square textures with dimensions that are powers of two. [...] Alternatively, an application can pack multiple images into a single texture resource and adjust the texture coordinates to address the proper region for each image. [...] D3DX provides functions..."

This seems to be a workaround for cards that do not support non power of two textures. It also allows the programmer to keep program size smaller by being more efficient with graphics.

These are my conclusions from the information I have read. Am I missing something?

[Pogacha]

Sorry for the late response
You can wrap it around and do your own rectangular surfaces system in OpenGL too, but this is not "Rectangular Textures".
Rectangular textures is a HARDWARE FEATURE, a card CAPABILITY.
I stand the confusion for the D3DX abstraction layer, if you call "texture" to the handle which D3D gives you it's understandable to call them "rectangular textures", but the world doesn't end with d3d, it is only a hardware abstraction layer .
Beware, I'm not saying you are wrong at any point, we were talking about different stuff.

Regards
Edit: Rectangular textures is not the right word, Non power of two textures is what i did mean
Why I wrote that? because the OpenGL extension.
http://oss.sgi.com/projects/ogl-samp..._rectangle.txt
Sorry

[oNyx]

Non power of two = NPoT

So... NPoT textures. One issue I had with NPoT textures was that the sampling points were slightly off. As shown in this image:

http://kaioa.com/k/badsample.png (zoomed in apparently)

Depending on the dimensions of the texture either one axis was off or both of em. Something like that isn't really visible in 3D, but it looks like a pile of crap in 2D.

All my textures are PoT now, but my texture loader automatically enlarges the canvas to the next PoT (and adjusts the texture coordinates automatically) if necessary.

If you enlarge the canvas (or if you use an atlas), texture repeat wont work anymore. Thats something to keep in mind. There are some shader tricks, which handle that, but its a bit too early to use em.

[luggage]

Another option is to get your engine to check the caps and see if NPoT are allowed. If they aren't split up the image you've loaded into smaller PoT textures. You end up drawing more polys for those images but it's not really that big a deal in 2D.

Otherwise if you use the other method displaying a 640x480 screen would mean you end up with a texture that's 1024x512?

[oNyx]

>Otherwise if you use the other method displaying a 640x480 screen would
>mean you end up with a texture that's 1024x512?

Yes. Well, it will get swapped away by OpenGL if it isn't used and other textures are required. So its not that bad.

Other than that you could use a 512x512 texture. If its created at that size it won't get that blurry, because its only filtered once. And for 1024x768 a 1024x512 texture can be used.

Splitting it up to PoT sizes is a pretty interesting idea, however.