A PSP emulator for Android, Windows, Mac and Linux, written in C++. Want to contribute? Join us on Discord at https://discord.gg/5NJB6dD or just send pull requests / issues. For discussion use the forums at forums.ppsspp.org.
These days, by default we always hash textures (although we do mark them as stable, keeping the textures around). But we still use the texture address as the main key in the hashmap, and the hash as an additional check that can force us to throw out the texture and re-hash. This means that for cases like #11929 where the game keeps overwriting the same texture, our texture cache is entirely ineffective.
So, it would probably make more sense to have the content hash be the key in the hashtable, but also to maintain a quick address->hash lookup table with some metadata, so we can still be avoid re-hashing textures that we have built up some confidence about if "lazy texture caching" is enabled.
This would fix the performance problem in Gran Turismo menus, and likely a few other things. I don't really see what could get slower.
This would be similar to the compat setting "Retain changed textures" (secondary texture cache) but a cleaner implementation.
(In fact, could also experiment with enabling that for GT...)
These days, by default we always hash textures (although we do mark them as stable, keeping the textures around). But we still use the texture address as the main key in the hashmap, and the hash as an additional check that can force us to throw out the texture and re-hash. This means that for cases like #11929 where the game keeps overwriting the same texture, our texture cache is entirely ineffective.
So, it would probably make more sense to have the content hash be the key in the hashtable, but also to maintain a quick address->hash lookup table with some metadata, so we can still be avoid re-hashing textures that we have built up some confidence about if "lazy texture caching" is enabled.
This would fix the performance problem in Gran Turismo menus, and likely a few other things. I don't really see what could get slower.
This would be similar to the compat setting "Retain changed textures" (secondary texture cache) but a cleaner implementation.
(In fact, could also experiment with enabling that for GT...)