Xenia: Texture Cache D3D12

[niko1point0]

I've noticed that some games are using thousands of textures in Xenia D3D12, and I think I have an idea for how to fix it. Sonic Unleashed is one of many examples, where you can go into a level, leave the level, and go back in, then the same textures will have been loaded multiple times (I pressed F3 to look at the counter)

I was looking at the following file
https://github.com/xenia-project/xenia/blob/d3d12/src/xenia/gpu/d3d12/texture_cache.cc

I was looking at the two following functions:
TextureCache::Texture* TextureCache::FindOrCreateTexture(TextureKey key)
TextureCache::ClearCache()

Could there be a record of how often each TextureKey is passed into FindOrCreate? Can there be a record of how much time has passed since each TextureKey has been passed into FindOrCreate?

As a result, can there be a feature where a texture is deleted if it's TextureKey hasn't been used in 5-10 minutes? Time can be adjusted of course. I think this will prevent memory from filling up, and then make it so games can be played longer without crashing.

Personally, I have 2gb of VRAM and 8gb of RAM, so my memory fills very quickly in some games, and then Xenia crashes

[niko1point0]

I have another idea. Currently, in several games, if you enter a level 1, then go to level 2, and then go back to level 1, then level 1's textures will be loaded twice.

In the texture cache, can you save the filename of each texture loaded, so that then if the Xenia wants to load a texture, and if the filename exists in the cache, then it will use the cache, and not load the texture a 2nd time?

Also, I've been posting a lot lately. If I am causing a distraction, or if I am being annoying, please tell me, and I will stop. I'm only trying to be helpful

[Triang3l]

There are no "file names", only memory addresses provided by the game and parameters of how to read from those, and addresses can be different depending on where in the game's run time a level was launched.

What we need is least-recently-used caching with old textures being eliminated when memory usage goes above a certain amount. It's a known issue, just never been high-priority.

Another good trigger for deleting textures is memory behind them having protection changed — this may indicate that memory was deallocated by the game (though it won't cover all cases because games can use custom heaps with custom allocators).

There are two things to consider here also:

• You must not delete textures used less than 3 frames ago as the GPU may still be rendering frames with them.
• A "free list" needs to be added to the descriptor cache to prevent fragmentation.

[Triang3l]

Implemented in d0c872527015ef90b4efd6e7d7996479de590a47.