Texture performance recommendations (2024)

Graphics and GPU Programming Programming

Quote:"Keep the textures small. The smaller the textures are, the better chance they have of being maintained in the main CPU's secondary cache."

I assume a cache hit would only have an effect on systems without enough VRAM to hold all the textures? If I use less than 100MB of textures and will only run on video cards with 128MB+ VRAM, does this still apply somehow?

That quote from the docs made me laugh. I don't know how old that is or why it's still in there, but textures, properly used, have almost nothing to do with the CPU cache. Okay I just Googled it and it goes all the way back to at least DirectX 3. The statement by itself is poppyco*ck. The CPU does not do texturing.

However, smaller textures do tend to result in better cache performance on the *GPU*. So to answer your question, even if all the textures fit in local video RAM, smaller textures will still tend to be more performant because the GPU has a texture memory cache. Reading texels out of the cache is faster than reading them out of local video memory.

Quote:"Use square textures whenever possible. Textures whose dimensions are 256x256 are the fastest. If your application uses four 128x128 textures, for example, try to ensure that they use the same palette and place them all into one 256x256 texture. This technique also reduces the amount of texture swapping. Of course, you should not use 256x256 textures unless your application requires that much texturing because, as mentioned, textures should be kept as small as possible."

Same thing. These statements can be carbon dated and if you touch them, they might crumble into dust. Well, sort of. Square textures were a good thing in the days of software rasterizers and Voodoo-class hardware. These days textures don't have to be square for optimal performance but it does help if the dimensions are powers of 2. Non-pow2 textures typically cannot be swizzled.

Quote:Would it benefit my performance if I added unused filler to my batched textures to make them square or a power of 2?

Maybe, maybe not. Padding/stretching a 257x257 texture out to 512x512 is quite expensive. But then of course it would be silly in most cases not to just sample that texture down to 256x256.

I think it's safe to say that in general, and all other things being equal, smaller textures suffer less risk of texture fetch stalls, and that power-of-2 dimensions tend to perform better than non-power-of-2.

Donavon KeithleyNo, Inky Death Vole!

Thanks for the quick reply but I still have no idea what to do. I have about 25k frames of 96x96 sprites for a 2D in 3D game. Each animation is composed of up to 13 frames. The easiest way to organize them would be to have each row of the "texture atlas" (a .dds filled with frames) be an animation sequence in a different direction. Assuming 8 directions, we're talking about a 1248x768 file (max) for each animation. Are these too large?

I'd rather not spend weeks organizing 25k frames just to find out (when I get a decent system) that my methodology is bad and spend more weeks to reorganize them properly.

3 other (less important) questions:

1. I've never seen GPU cache discussed in an article or even a press release, although I've seen mention of Z cache and texture cache. I've searched google, GD, DX docs and ati and nvidia's developer sites. How large is the cache on a x800XT or 6800U? How many levels of cache? etc.

2. Is the performance recommendation for tilesets different? With sprite rendering, its most likely that only one frame will be displayed at any given time (only one of each character, but there may be multiple animals/monsters on the screen using the same model). With a tileset though, you're likely to be displaying many tiles from that set simultaneously. So I would expect you'd want the tileset to have as many tiles (likely to be displayed concurrently) as possible and still fit in texture cache. ie. when displaying a terrain background composed of 300 tiles you'd want all of these to be in the same terrain tileset assuming they can all fit into cache so that the latter 299 D3DX draw calls will all result in cache hits.

3. Is DX Texture Compression useful for anything but reducing (virtual) memory access? It seems to me the textures would still have to be decompressed either at load time (takes up just as much VRAM and increases load times) or at run time (significant performance hit). Although I'm sure it has been optimized so that it performs better than using standard compressed formats, it seems that using plain .dds files is the best way to go if you count on havings lots of VRAM available.

I'm sure lots of you have done performance testing and so can at least give good guesses for me to rely on.

The 256x256 figure is likely old. I can't really think of any newer games using anything LESS than 256x256.

Quote:Original post by AvalonX86
Assuming 8 directions, we're talking about a 1248x768 file (max) for each animation. Are these too large?

In a sense that's up to you -- when you define your minspec. Clearly it's too large for a Voodoo 1 (max 256 x 256) but not for a GFFX 5950 (4k x 4k). If you Google around there are a handful of caps databases where you can check the limitations of various parts.

Quote:1. I've never seen GPU cache discussed in an article or even a press release, although I've seen mention of Z cache and texture cache. I've searched google, GD, DX docs and ati and nvidia's developer sites. How large is the cache on a x800XT or 6800U? How many levels of cache? etc.

I don't think the specific values are public information. If you're wondering whether you're over-stressing the texture cache, make all your textures 1x1 and if your frame rate goes up, you are.

Quote:2. Is the performance recommendation for tilesets different? With sprite rendering, its most likely that only one frame will be displayed at any given time (only one of each character, but there may be multiple animals/monsters on the screen using the same model).

If you're doing 2D rendering where you have a 1:1 texel to pixel relationship, then the size of the overall texture isn't going to have much impact on the cache performance because you have good locality of reference. Using a large texture in 3D with no mipmapping -- that's a different story.

Quote:With a tileset though, you're likely to be displaying many tiles from that set simultaneously. So I would expect you'd want the tileset to have as many tiles (likely to be displayed concurrently) as possible and still fit in texture cache. ie. when displaying a terrain background composed of 300 tiles you'd want all of these to be in the same terrain tileset assuming they can all fit into cache so that the latter 299 D3DX draw calls will all result in cache hits.

The main thing to focus on in this situation is minimizing texture switches. Load a texture, draw everything that uses it, then move on to the next texture.

Quote:3. Is DX Texture Compression useful for anything but reducing (virtual) memory access? It seems to me the textures would still have to be decompressed either at load time (takes up just as much VRAM and increases load times) or at run time (significant performance hit). Although I'm sure it has been optimized so that it performs better than using standard compressed formats, it seems that using plain .dds files is the best way to go if you count on havings lots of VRAM available.

No, compressed textures *will* help your texture bandwidth at runtime as well as your memory footprint. The DXT formats are designed to be hardware-friendly for decompression. The chip will load in compressed MxN blocks and special logic in the TMU will twiddle the bits to feed uncompressed values back to the shader unit. At least that's my understanding -- I am not a hardware engineer.

Donavon KeithleyNo, Inky Death Vole!

Thanks for your advice guys! Assuming no one else chimes in (especially with their experience) I'll start working on organizing the artwork in the size I described.

Donavon: By texture switches do you mean changing the display rect of the tileset file or switching to a different tileset entirely. I'd figure if the entire tileset is loaded into cache there would be no performance hit on the video card (it would only have to wait for the cpu to change the RECT). This would likely total a smaller delay than sorting through the map before any draw calls to minimize the amount of changes to the display rect.

Also, I was hoping to get feedback because although I know how to test these things, I can't. My decent dev system was stolen and unfortunately all my code and tools for my game with it (valuable lesson learned about backing up elsewhere). Anyways, I'm using a 4 year old laptop (w/ Savage/IX (DX6? part)) until I can afford a new system (prolly in 6 months to a year). Anyways, I don't expect to be distributing my game for a couple years at least, at which point I feel the standard computer will have a video card like that of a x800/6800 so I'm trying to keep that in mind while also limiting myself to things my current system can handle doing: coding AI and controls, loading graphics, writing tools, outlining my ideas, level design, and lastly organizing artwork (and code once I have some again). My current integrated video allows a texture size of 2048x2048 so saving entire animations to a single file should work (and as long as I can get 8+ fps in retail I'll keep making them large so I don't have to redo this all later).

So now I'll start working on a tool to splice all the frames together for each animation and maybe convert to dds. I haven't done this before so it should be a lot more fun than redoing stuff. Also, if anyone is curious about my questions and has a good video card, hopefully I'll have enough of an engine and organization so a bunch of different scenarios can be sent to you and tested to satisfy our curiosity.

P.S. Can anyone confirm Donavon's statement about DXTC? I have read this on the web before but the reasons are never explained and no data is included to back it up. Maybe the GPU in many apps is usually just performing noops so it can be uncompressing textures as they display with no real penalty (Obviously a VRAM savings) rather than doing nothing? Things might change with lots of shader use though.

P.P.S I *am* a hardware engineer but severely underemployed :)

[Edited by - AvalonX86 on August 16, 2004 4:27:02 AM]

Quote:P.P.S I *am* a hardware engineer but severely underemployed :)

Oh, well in that case just look up the DXT formats. It should be easy for you to see how they can be decompressed with a modest number of logic gates. DXT1 is a 4x4 block using a 2-bit linear interpolation between two 16-bit colors. For those 16 texels it's just a 64-bit fetch and in the decoding the only thing that's not trivial (for a non-hardware-engineer like me) is calculating 1/3 the difference between the two. Maybe they just use a small PLA. Anyway, the rest is cake.

Donavon KeithleyNo, Inky Death Vole!

DXT textures tend to be faster than uncompressed because memory bandwidth is usually the bottleneck. Compressed textures consume less memory.

I think the best way for you to go is not to arrange your tilesets to any specific size/arrangement, but let your engine handle that dynamically. This can then choose the best texture size and format for the video card it is running on (and any options the user sets), and put commonly used tiles onto the same tileset to reduce texture changing.

Quote:Original post by DBX
I think the best way for you to go is not to arrange your tilesets to any specific size/arrangement, but let your engine handle that dynamically. This can then choose the best texture size and format for the video card it is running on (and any options the user sets), and put commonly used tiles onto the same tileset to reduce texture changing.

This is an interesting idea that hadn't occured to me. If I'm going to build a test app to determine the optimal file size and another to splice frames together I might as well integrate both into my game and make good use of them. The use profiling, however, will add overhead (in the profiling itself, swapping textures between sets, and the storing/lookup of an individual texture's present location). It obviously also adds a fair amount of complexity as well. It does sound like it would be worth it, however. Any advice w/ regard to these concerns or examples of engines that do this currently?