Update vram on render (optionally or lazily)

[unknownbrackets]

An unknown quantity of games may use this functionality for various purposes, so an option to commit to VRAM would be useful to test.

Some notes:

• Might affect block transfers?
• Might affect direct vram memory access?
• Textures are being handled more efficiently in Render to Texture #465.
• May be used to check for lens flare or potentially even blit.

We would either add an option to always update vram, or potentially find a way to detect it / do it lazily. Options there include:

• Check for certain kinds of cache instructions and syscalls.
• Check for a drawsync.
• Watch for certain GE signal behavior.
• Use a dirty flag and check for memory reads from VRAM (may not be that expensive in jit.)

Note discussion in #109.

-[Unknown]

[hrydgard]

Also, in the long run, a software renderer that renders directly to the vram would be nice for ultimate accuracy, would also enable the many homebrews that mix HW rendering and "pixel poking" to work correctly.

[unknownbrackets]

I wonder if we could at least do it in this case without huge performance issues:

http://report.ppsspp.org/temp/recent/kind/192

FWIW, 3rd Birthday calls this:
sceDmacMemcpy(dest=44178000, src=04000000, size=557056)

Right before a black screen. Clearly it's trying to blit the framebuffer. Another game, Vempire, has always had weird graphic issues, and it seems to do a lot of this:

sceDmacMemcpy(dest=04110000, src=04088000, size=557056)
sceDmacMemcpy(dest=04110000, src=04000000, size=557056)

That should be easily detectable and probably not a huge penalty to other games.

-[Unknown]

[hrydgard]

Oh yeah, I'm all for detecting cases like that and doing the right thing. If both source and destination are FBOs or textures maybe we can get away with doing it without glReadPixels too.

[unknownbrackets]

Cool. I gave it an intial shot using fbo_bind_as_render_target() and fbo_bind_color_as_texture(), but I'm not sure what I'm doing and it doesn't seem to work for either of these two games.

In the case of 3rd Birthday:
UpdateMemory: 04178000 <= 04000000
CopyFBO: 0000000000000000 <- 000000000DEBB6A0 (would be readpixels, didn't do this)
SetTexture: 04178000

In the case of Vempire, it seems to copy to 04110000 (which never has an FBO created for it), and the copy back from it later to "clear" the screen.

Here's my initial attempt:
unknownbrackets/ppsspp@master...fbo-invalidate

-[Unknown]

[7331Squall]

Since I opened that said #2236 , and also the #2065 , I gotta wonder if they aren't going to get somewhat fixed once this one is resolved...

[HermitCrap]

Just wondering. Is it possible to change the GE Saving to VRAM just by changing the Hex for fb_address in ppsspp/GPU/GLES/Frambuffer.cpp, line 355? Since "textureCache_->NotifyFramebuffer(vfb->fb_address, vfb);".

[hrydgard]

Nope, it requires a lot more code. We haven't implemented saving the rendered image to RAM at all.

[HermitCrap]

Hope someone implement this ASAP...

edit: Search around the JPCSP code and I found GEProfiler.java & GETextureManager.java which I believe contains the code to save the GE to VRAM instead of Texture. I'm not entirely sure as I'm a noob at codes and stuff, but I hope this will give other people a head start. It seems to import other java files to "map" the codes together. It also uses the same hash code for START_VRAM address which is 0x04000000.

[unknownbrackets]

Another example of this is Legend of Heroes 1. When you save, it takes a screenshot and stores it as the save icon.

It does this by doing a block transfer:
04000000/200 -> 09830740/200, 480x272x4 (0,0)->(0,0)

If we supported downloads in block transfers (when the destination isn't a fbo, which there's a separate bug for), this would work and would not require making the game unplayably slow on mobile.

-[Unknown]

[hrydgard]

Indeed, that wouldn't be too hard to do.

[dbz400]

Yep , it did something similar in YS seven as well .It now only work in framebuffer to memory mode.

[dbz400]

@unknownbrackets Just curious what is "downloads in block transfer" ?

[hrydgard]

It means that the game does a block transfer "down" from VRAM to RAM, instead of the other direction which is more common. We could add special handling code for this case which would allow those screenshots to work while probably not slowing games down at all.

[dbz400]

I see.Hope it is not very difficult to implement

[unknownbrackets]

Well, this is currently supported optionally, so I think it's time to close this one. We still have others (like #3515) for more specific cases.

-[Unknown]