Texture Sizes in Video Ram

Discussion in 'Game Development (Technical)' started by Jamie W, Nov 21, 2006.

  1. Jamie W

    Original Member Indie Author

    Joined:
    Apr 16, 2006
    Messages:
    1,211
    Likes Received:
    0
    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?
     
  2. Bad Sector

    Original Member

    Joined:
    May 28, 2005
    Messages:
    2,742
    Likes Received:
    5
    Both must be powers of two, for optimized access. In some cases, this:
    Code:
    texel_offset = (texel_v << o) + texel_u
    
    is fast, but in others
    Code:
    texel_offset = (texel_u << o) + texel_v
    
    is faster. Depends on the driver, implementation, etc. Note that the above are optimizations of:
    Code:
    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.
     
  3. Jamie W

    Original Member Indie Author

    Joined:
    Apr 16, 2006
    Messages:
    1,211
    Likes Received:
    0
    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...

    :eek:
     
  4. Bad Sector

    Original Member

    Joined:
    May 28, 2005
    Messages:
    2,742
    Likes Received:
    5
    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.
     
  5. zoombapup

    Moderator Original Member

    Joined:
    Nov 25, 2004
    Messages:
    2,890
    Likes Received:
    0
    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).
     
  6. Jamie W

    Original Member Indie Author

    Joined:
    Apr 16, 2006
    Messages:
    1,211
    Likes Received:
    0
    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.

    :)
     
  7. Bad Sector

    Original Member

    Joined:
    May 28, 2005
    Messages:
    2,742
    Likes Received:
    5
    Actually you've given yourself a very good reason. Just see how many times are repeated.
     
  8. Pogacha

    Original Member

    Joined:
    Jan 21, 2005
    Messages:
    605
    Likes Received:
    0
    Also some old video cards requieres textures to be squared.
     
  9. Brian A. Knudsen

    Brian A. Knudsen New Member

    Joined:
    Aug 17, 2006
    Messages:
    72
    Likes Received:
    0
    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.
     
  10. oNyx

    Original Member

    Joined:
    Jul 26, 2004
    Messages:
    1,212
    Likes Received:
    0
    First time I heard that. Even a Voodoo 1 is fine with rectangular textures.
     
  11. Donavon Keithley

    Original Member

    Joined:
    Aug 5, 2004
    Messages:
    110
    Likes Received:
    0
    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.
     
  12. Pogacha

    Original Member

    Joined:
    Jan 21, 2005
    Messages:
    605
    Likes Received:
    0
    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.
     
    #12 Pogacha, Nov 22, 2006
    Last edited: Nov 23, 2006
  13. oNyx

    Original Member

    Joined:
    Jul 26, 2004
    Messages:
    1,212
    Likes Received:
    0
    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.
     
  14. Pogacha

    Original Member

    Joined:
    Jan 21, 2005
    Messages:
    605
    Likes Received:
    0
    Yes, I completely agree.
    And yes, squared textures are only anecdotal at this point.
     
  15. lapskaus

    Original Member

    Joined:
    Jun 16, 2006
    Messages:
    51
    Likes Received:
    0
    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)
     
  16. zoombapup

    Moderator Original Member

    Joined:
    Nov 25, 2004
    Messages:
    2,890
    Likes Received:
    0
    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.
     
  17. niX_BB

    Original Member

    Joined:
    Nov 15, 2005
    Messages:
    12
    Likes Received:
    0
    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. :D
     
  18. TJM

    TJM
    Original Member

    Joined:
    Oct 29, 2004
    Messages:
    35
    Likes Received:
    0
    Does D3DX_FILTER_NONE eliminate the need for the power of 2?
     
  19. dxgame

    Original Member

    Joined:
    Mar 11, 2005
    Messages:
    267
    Likes Received:
    1
    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) :)
     
  20. Pogacha

    Original Member

    Joined:
    Jan 21, 2005
    Messages:
    605
    Likes Received:
    0
    No way!
    "Rectangular" non power of two textures is an additional hardware feature of some cards only.
     

Share This Page

  • About Indie Gamer

    When the original Dexterity Forums closed in 2004, Indie Gamer was born and a diverse community has grown out of a passion for creating great games. Here you will find over 10 years of in-depth discussion on game design, the business of game development, and marketing/sales. Indie Gamer also provides a friendly place to meet up with other Developers, Artists, Composers and Writers.
  • Buy us a beer!

    Indie Gamer is delicately held together by a single poor bastard who thankfully gets help from various community volunteers. If you frequent this site or have found value in something you've learned here, help keep the site running by donating a few dollars (for beer of course)!

    Sure, I'll Buy You a Beer