Post Reply 
 
Thread Rating:
  • 1 Votes - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Texture and vertex caching and invalidations
04-27-2013, 02:06 AM (This post was last modified: 04-27-2013 02:06 AM by [Unknown].)
Post: #1
Texture and vertex caching and invalidations
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]
Find all posts by this user
Quote this message in a reply
04-27-2013, 05:22 AM
Post: #2
RE: Texture and vertex caching and invalidations
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.
Find all posts by this user
Quote this message in a reply
04-27-2013, 06:57 AM
Post: #3
RE: Texture and vertex caching and invalidations
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.
Find all posts by this user
Quote this message in a reply
04-27-2013, 07:13 AM
Post: #4
RE: Texture and vertex caching and invalidations
(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 Smile

♦ Intel Core i7-6700HQ | 16 GB RAM | NVIDIA GeForce GTX 960M | Debian Testing
♦ Intel Core i7-2630QM | 4 GB RAM | NVIDIA GeForce GT 540M | Debian Testing
♦ PSP-3004 | 6.60 PRO-C2
Find all posts by this user
Quote this message in a reply
04-27-2013, 08:58 AM
Post: #5
RE: Texture and vertex caching and invalidations
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]
Find all posts by this user
Quote this message in a reply
04-27-2013, 10:46 AM
Post: #6
RE: Texture and vertex caching and invalidations
Hey i Tried the 161 build and the new texture cache made all the games go much much slower with lots of hangups
Find all posts by this user
Quote this message in a reply
04-28-2013, 06:46 PM
Post: #7
RE: Texture and vertex caching and invalidations
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.

Windows 7 x64: Intel Core i5 4570 @3.6 Ghz, ATI Radeon HD 7870
Android 4.4.2 (CM11): Samsung Galaxy S3 @ 4x1.6 Ghz CPU, 600Mhz GPU
Visit this user's website Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump: