PSP cache HOWTO/FAQ

[jsgf]

I've been seeing a fair amount of confusion about cache issues here, along with misleading/incomplete advice about how to deal with them.

So I decided to write up a HOWTO for dealing with PSP cache issues: http://goop.org/psp/cache-howto.html

This is a first draft, and I'd love to have comment/suggestions/corrections for it.

[ChaosKnight]

This is extremely helpful, thanks for posting it!

[holger]

nice!

maybe worth noting that cache-line-aligned unchached memory blocks should have a multiple-of-64-byte size, in order to avoid cached/uncached aliasing at the end of buffer.

Can you make this part of the psp-wiki?

[jsgf]

I've updated it to note that allocatons should be cacheline multiples in size too. I also spelled out the implciations of write-back caching.

I'm planning to put it on the wiki when it settles a bit, and I've added some diagrams. It's easier to edit locally for now.

[jimparis]

Rather than all the mess with uncached pointers and cache line sizes, can't you just do business as usual and force a writeback before telling the GE to use it? I haven't used the GE; obviously this wouldn't work if there's a case where you're changing the data as the GE reads it.

[jsgf]

Rather than all the mess with uncached pointers and cache line sizes, can't you just do business as usual and force a writeback before telling the GE to use it?

You could; that would handle the case of writing commands to be written by GE (or whatever). But it isn't the most efficient path (uncached writes seems faster, I'm guessing because of reduced cache pollution), and a lot of code is already using uncached pointers (mostly in unsafe ways).

Also, if you're reading back memory which has been written by hardware, then you also need to make sure the cache has been invalidated, and/or use uncached reads.

I haven't used the GE; obviously this wouldn't work if there's a case where you're changing the data as the GE reads it.

Well, that would be inherently buggy code anyway.

[jimparis]

I haven't used the GE; obviously this wouldn't work if there's a case where you're changing the data as the GE reads it.

Well, that would be inherently buggy code anyway.

Concurrent memory access can surely work if you're careful (think Dekker's algorithm), and this might be useful for future work with the ME. But I digress; your guide is certainly useful, thanks.

[jsgf]

Concurrent memory access can surely work if you're careful (think Dekker's algorithm), and this might be useful for future work with the ME.

Possibly; though Dekker's algorithm also assumes strict in-order writes. I'm guessing the PSP does that, but it is a stronger requirement than simply uncached writes.

[holger]

I haven't used the GE; obviously this wouldn't work if there's a case where you're changing the data as the GE reads it.

Well, that would be inherently buggy code anyway.

Concurrent memory access can surely work if you're careful (think Dekker's algorithm), and this might be useful for future work with the ME. But I digress; your guide is certainly useful, thanks.

The GE signal command may be useful for this, but I have no idea whether anybody found out yet how they work.

[jsgf]

The GE signal command may be useful for this, but I have no idea whether anybody found out yet how they work.

I played with it for a while, but didn't have much success; I could never get a callback from it. But that's quite a different matter from actually playing with the GE's command memory as it reads it...

[holger]

see http://forums.ps2dev.org/viewtopic.php?t=3764