Framebuffer-bind sequence numbers #15853
Conversation
hrydgard
added
GE emulation
| u16 renderWidth; | ||
| u16 renderHeight; | ||
|
|
||
| float renderScaleFactor; | ||
| // Attempt to keep track of a bounding rectangle of what's been actually drawn. However, right now these are not | ||
| // used in a very detailed way (they're only ever 0 or equal to width/height) |
There was a problem hiding this comment.
That's not exactly true. If the framebuffer is "resized" multiple times during a frame, this may no longer match width or height, and be a more correct value of what the width and height were detected as last time an actual draw occurred. I don't believe they're reset to 0 on resize.
-[Unknown]
There was a problem hiding this comment.
Yeah, you're right. I'm updating the comment.
|
|
||
| u16 usageFlags; | ||
|
|
||
| // These are used to track state to try to avoid buffer size shifting back and forth. | ||
| // Though that shouldn't really happen, should it, since we always grow, don't shrink? |
There was a problem hiding this comment.
We do resize down, if the size has shrunk for a while and the framebuffer is also larger than the stride. At this point, the "safe" size is probably a lie, and I think we had various issues with readbacks, so this resizes down to avoid them.
An example would be a game that always uses the address 0x00154000 for temp buffers, and uses it for a full-screen effect for 3 frames, then goes back to using it for character shadows or something much smaller.
-[Unknown]
There was a problem hiding this comment.
I see, that makes sense. I'll revise the comment.
hrydgard
force-pushed
the
framebuffer-sequence-numbers
branch
from
e0463cb
to
078fc88
Compare
This allows us to identify which of two framebuffers was bound for rendering to the most recently, even within a frame.
Not actually used for anything yet, but will be used in the solution for #15728 , and #15777 will be updated to update the depth sequence number separately. When we have the sequence numbers, we can possibly remove the separate vector for depth buffer tracking, and instead just loop through and get the latest.
32 bits is very likely enough for these (max 2 billion if we keep signed, say 40 binds per frame as an extreme case, and 60 frames per seconds, that's half a year of straight playtime without restarting PPSSPP).
This is a separate PR because it cleans up documentation, changes some variables to smaller types to compensate for the newly added ones in this already large struct, etc.
Better ideas about naming these will be considered, not very fond of my current choice.