Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
hrydgard opened this issue Nov 4, 2018 · 4 comments
Closed

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

hrydgard opened this issue Nov 4, 2018 · 4 comments

Comments

@hrydgard
Copy link
Owner

hrydgard commented Nov 4, 2018

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
Copy link
Collaborator

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
Copy link
Owner Author

hrydgard commented Nov 4, 2018

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
Copy link
Owner Author

hrydgard commented Nov 4, 2018

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
Copy link
Owner Author

hrydgard commented Jan 8, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants