hrydgard / ppsspp

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.
https://www.ppsspp.org
Other
11.38k stars 2.19k forks source link

Idea: Virtual GPU readbacks to speed up some games #11528

Closed hrydgard closed 5 years ago

hrydgard commented 6 years ago

There are a number of games that read back from VRAM to RAM, or from VRAM to another region in VRAM that is never created as a framebuffer, but never actually do any CPU processing on the image before using it as a texture. Currently, for any block copy from VRAM to RAM or VRAM->VRAM copies to fresh memory we issue a full readback.

We could use compat settings to whitelist these, and when this flag is set for a game, any readback will simply create a new virtual framebuffer at the address if one doesn't already exist there, and do a simple copy to it (Framebuffer instead of texture because of the way our existing infrastructure in FramebufferCommon works). This lets the image data stay on the GPU, eliminating the very costly readback sync.

One example of a game that I believe could get a considerable speed boost this way is Digimon Adventures, which has long been complained about as being slow on mobile due to its constant readbacks of the framebuffer for the toon effect.

A wrinkle in the plan is that the current framebuffer code assumes that framebuffers have VRAM addresses, but should not be a big deal to fix or take into account.

Anyway, the first part (VRAM->fresh VRAM) could be as easy as adding some code to the end of FindTransferFramebuffers which would create a brand new framebuffer if one isn't found, if the game is whitelisted to allow this (or maybe always if the dest is VRAM...)

unknownbrackets commented 6 years ago

So we would manually flag games where we expect memory copies are never accessed via CPU, essentially, right?

Another scenario to be careful of (I'm not sure it's likely) is texturing. Currently, we assume many things about render-to-texture that are usually true. It's possible that avoiding more copies from VRAM to RAM/VRAM may make these assumptions less likely, making it harder to detect a render-to-texture, especially if the texture is not aligned to the blit.

I wonder if it'd make sense in some cases to keep a "pagemap" on CPU and update it every time RAM/VRAM is accessed by CPU. Obviously, this would be slower and require the slowmem path, and wouldn't even fix screenshots the first time around, etc. It could at least be useful to build a level of confidence that setting this flag is "safe" for a game, though...

-[Unknown]

hrydgard commented 6 years ago

Yes, or until we find good enough heuristics - but without such a pagemap I don't know if it's possible.

This would really only be a stopgap until we implement that pagemap...

hrydgard commented 6 years ago

Also, this would let use remove the "knownFramebufferRAMCopies" hack for MotoGP as it's a more generalized version of the same thing.

I think I'll give it a shot soon.

hrydgard commented 5 years ago

While there are more games that could benefit, this was basically implemented in #11531 and I'm thus closing this issue.