forums.ps2dev.org

[PeterM]

Hello,

I've been trying without much success for the last few days to use the limited VRAM space available as a LRU (least recently used) cache for textures stored in system memory.

In case anyone is wondering why, it's because I'm continuing my port of Quake to the PSP by replacing Quake's software rasterizer subsystem with a GU version.

I'm starting off small, by just porting the blitting system. Quake caches textures and images in system memory for me. Unfortunately, I can't use sceGuCopyImage to copy them to VRAM, since they are not aligned or powers of two in size. Because the source data isn't aligned, I have to use memcpy to manually copy the bytes over.

I manage VRAM for myself using a Pool which allocates VRAM in chunks which are multiples of 1K in size.

When I need to use a new texture, I allocate as many chunks as required from VRAM, them memcpy the bytes over. Obviously I could be dirtying memory which is in the texture cache (what is it, 16K?) so I should call sceGuTexFlush.

But when do I call it? I've tried calling it before and after copying the bytes, but I get texture corruption, which I presume means a dirty cache.

And since I'm using memcpy instead of sceGuCopyImage, do I need to call sceGuTexSync?

I could really do with some help, it's driving me crazy! ;-)

Pete

[jsgf]

Are you using cached or uncached addresses for VRAM? If you're using cached addresses, are you flushing the Dcache before trying to use the texture?

[PeterM]

I think I fixed the problem - it wasn't related to my use of sceGuTexFlush.

Quake was moving the image memory around, causing me to be using memory which it had stomped over... Oops.

Now I make my own copy of the textures, which seems to have solved the problem.

I was using cached addresses (initially getting my VRAM base pointer from sceGeEdramGetAddr()) but I was using sceKernelDcacheWritebackRange() to flush the relevant part of the Dcache after uploading the texture.

Thanks anyway for your help,

Pete