Post Reply 
 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
A better way to handle texture scale/cache
06-18-2014, 10:37 AM
Post: #1
A better way to handle texture scale/cache
I don't actually understand how PSP works, so the following are most my own opinion - basically guessing. so correct me if I'm wrong.

(And... excuse me for making this post so long... English is not my first language I've no idea how I can make it shorter.)

---

I've been messing around with PPSSPP's texture cache/scaler for quiet a few days, trying to get more textures scaled and reduce the rescale on the same texture (it happens a lot, I'll explain later)

The problem with PPSSPP's current methods is, it doesn't scale the "real" texture, instead, it gets which address the texture is loaded in ram, and grab the texture size of ram after that address (let's call this "texture-ram" from now for convenience)

This works fine for most circumstances, but it leads to a problem that some times the unused part of texture-ram is reused for other usage, mostly when displaying a 480x272 picture, it takes a 512x512 texture and the rest part of texture-ram is not relevant to texture, could be used for anything else as available memory - when it's being used, it may very well be different any moment (even within a single frame)

So here comes the problem: currently, we're hashing from texture-ram, the changing of the unused part in texture-ram leads to the changing of hash, so we got the different hash of the exactly same texture and consider it has been changed - then the cache of this texture is removed, and generated again.

This is a total waste of resource, it may not be so noticeable if you don't enable texture scale feature since we often run PPSSPP on platforms far more powerful than a real PSP, we can handle it anyway. But if you enable texture scale, you may very well notice the performance drop caused by this design flaw in a lot scenes in a lot games (but you didn't, I'll explain why right away)

So PPSSPP comes up with a solution of not scaling textures updating too frequently and limit the amount of textures being scaled per frame. That's why you didn't notice the performance drop I mentioned in the past paragraph and you may very well notice that some textures are not scaled as you intended to.
(current limit from the latest git build is if a texture updates more frequently than once per 6 frames, don't scale it. If more than 256x256 of textures is scaled this frame, no more scaling this frame)

---

(Again, I apologize for being wordy x_x I hate myself about this as well as you might right now.)

What I'm thinking is, when a texture is being loaded:

(Pseudo-code, @variable, $scaleFactor is a variable contain info of scale level, scale method... used for the "key" of cache)

Code:
@hash = hash(texture1)
if ( TextureCache[@hash].key == $scaleFactor ) {
    // cache hit, return from cache
    return TextureCache[@hash].data
} else {
    // no hit, store it into cache
    @textureData = ScaleTexture(texture1)
    TextureCache[@hash].key = $scaleFactor
    TextureCache[@hash].data = @textureData
    return @textureData
}

So basically, I want to move the hash part from memory to when the texture is actually being loaded, but so far I have no idea where the loading part actually is and I don't really have enough programming skill to achieve what I'm thinking...

unknownbrackets and hrydgard has explained a lot to me in this issue #6256 on github but I don't really get everything they said (stupid me x_x)
You may want to check that issue (sorry I don't have the permission to post links) if you don't understand what I said above, there're some screenshots in it.
Find all posts by this user
Quote this message in a reply
Post Reply 


Messages In This Thread
A better way to handle texture scale/cache - RadarNyan - 06-18-2014 10:37 AM

Forum Jump: