Texture and vertex caching and invalidations

[[Unknown]]

Different games have different requirements here, different misuses, and different signals to the emulator.

To define what we have now:
* Vertex cache: caches only larger vertex arrays, but works well. Causes minor glitches in a few games. Turns on and off.
* Texture cache: caches all textures. Works fairly well but causes some minor glitches or slowdowns in a few games. Sometimes uses too much VRAM. Not configurable.
* FBO cache: not exactly a cache, but similar to one. Uses up VRAM too, but kept mostly in check. Controlled by buffered rendering, sorta.

Games provide the following signals:
* GE block transfers: currently invalidates textures only. Not configurable. Could potentially do something with FBOs and vertices.
* GE texture flush: seems to be generated entirely too often, but might be a signal to rehash textures. Currently ignored.
* cache CPU instruction: indicates updates in the Icache, Dcache and secondary cache. Currently ignored.
* sceKernelDcache*: indicate updates to the Dcache. Not configurable. Works reasonably well but can slow down games, and many lazy games abuse it.
* Uncached memory addresses: indicates slower access to uncached memory. May indicate a more volatile resource. Currently ignored.

We also have the following mechanisms on top:
* Hashing: textures and vertices are hashed using progressive backoff. Upside is this detects changes, downside is it causes "jumping" and eats time. Not configurable.
* Decimation: all three are deleted if they are not used within X frames. This is mainly to save VRAM, but for some devices/games it's not enough. Not configurable.

I'm not a fan of per-game options, or incredibly detailed options (at least in the UI), but there seem to be many things we could make more controllable here. What I'm not sure is what people would want to configure. For example, a "high" (max speed, max glitches), "medium" (e.g. the current way), and "low" (slower, minimum glitches) might make sense.

Further options to control decimation for VRAM use might make sense too. For example, a mobile device with tons of RAM could decimate less often to try to maximize speed. Another mobile device or cheaper desktop card could decimate more often to keep VRAM free.

Any thoughts?

-[Unknown]

[livisor]

I believe it is too soon for per game settings,maybe after having video/sound, a decent compatibility and support for vr and intel phones we could add that.

[Henrik]

I think the way to go is to find a happy medium of defaults that work well for 95% of games, and then have an ini file of per-game "profiles" only for the remaining 5%. Since those settings will be ini-only and not exposed in the UI, they can be pretty detailed and we don't need to simplify to "high", "medium", "low".

The only issue then is that an average end user has little control over the tradeoff between glitches and performance in the very few cases where some glitchy caching method might lead to substantially better performance. We could possibly then have multiple such settings profiles per game though which would solve that.

[vnctdj]

(04-27-2013 06:57 AM)Henrik Wrote:  I think the way to go is to find a happy medium of defaults that work well for 95% of games, and then have an ini file of per-game "profiles" only for the remaining 5%. Since those settings will be ini-only and not exposed in the UI, they can be pretty detailed and we don't need to simplify to "high", "medium", "low".

I like the idea to make .ini files for games who have problems... These .ini files could be added to the thread of each game in question

[[Unknown]]

Well, I think that never rehashing textures unless explicitly invalidated, caching all vertices (even smaller ones), and ignoring the cpu cache instruction (which we do now, but in my tests I tried jitting it / making it invalidate per the MIPS manual) could gain a good bit of performance and definitely work on some games.

In contrast, listening to the cache instruction (which I did not write a hugely efficient implementation) for both vertices and textures gave a 10% hit, but fixed the games I know of that have glitches when vertex cache is enabled. It was still faster than when the cache is off. I was thinking this could be improved by instead keeping a list of invalidated ranges, consulting them on use, and resetting once per frame or something. Not sure, maybe that'd be slower if they invalidate a lot of times per frame...

-[Unknown]

[vontman]

Hey i Tried the 161 build and the new texture cache made all the games go much much slower with lots of hangups

[kevke96]

It is probably to soon for per game options, but once we got a good compatibility, I would be grateful if you could implement switches for as much as possible. Then the testers here could work on getting the most out of each game individually.