PSP texture cache usage

Discuss the development of new homebrew software, tools and libraries.

Moderators: cheriff, TyRaNiD

Post Reply
Loothor
Posts: 6
Joined: Wed Sep 07, 2005 3:12 am

PSP texture cache usage

Post by Loothor »

So I've got an app running using DXT1, 3, and 5 textures and a VRAM-management scheme that makes sure all textures are copied to VRAM before usage. Currently, I have few enough textures that they all fit in VRAM at the same time, so everything is copied on the first render and then just stays resident in VRAM.

Before I moved all the textures to VRAM, my program ran at 30fps when I used textured objects and 60fps when I didn't use the textures. I expected to get the textured versions running at 60fps with the speed increase from moving them to VRAM, and lo and behold, not at all. So I've been racking my brain to figure out why my textured stuff is so slow, and then it hits me... the texture cache. I have some fairly large polygons that have fairly large textures on them (I think in one case I have a rectangle with an entire 256x256 DXT5 mapped on it).

I'm assuming things would be much faster if the texture portion used in each render command fit into the texture cache, but this brought up a couple of questions in my mind that I think somebody here could enlighten me on:

1) What is the texture cache size? I think I read 8KB somewhere, but I'm not sure and I can't seem to find anything solid about it here.

2) Assuming it is 8KB, it is my understanding that a DXT-compressed texture is actually decompressed into 32-bit format in the texture cache... this would seem to mean that I should try to keep my DXT texture chunks used in each render command to 64x32 or smaller... is that correct or am I smoking bad crack again?


Thanks for any help... and the SDK is awesome, big kudos to all those that worked on it... you guys rock.
chp
Posts: 313
Joined: Wed Jun 23, 2004 7:16 am

Post by chp »

You are correct, the texture cache is VERY important on the PSP (as it was on the PS2). From experiments it seems to be 8kB, so that means it's 64x32 in 32-bit, 64x64 in 16-bit, 128x64 in 8-bit and 128x128 in 4-bit (the sizes are qualified guesses by looking at the PS2). Ordering your draws so that locality in uv-coordinates is maximized will make sure your rendering is optimal.

And yes, DXTn is decompressed into 32-bit when loaded into the cache, so what you gain in shrinking the texture-size, you lose in texture-cache. If you can, use 4- or 8-bit textures, which will allow a much larger area to be kept in the cache.
GE Dominator
Post Reply