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

Framebuffer-bind sequence numbers #15853

Merged
merged 4 commits into from
Aug 17, 2022
Merged

Conversation

hrydgard
Copy link
Owner

@hrydgard hrydgard commented Aug 16, 2022

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.

@hrydgard hrydgard added GE emulation Backend-independent GPU issues Code Cleanup Cleanup to make future work easier. Needs to be done sometimes. labels Aug 16, 2022
@hrydgard hrydgard added this to the v1.14.0 milestone Aug 16, 2022
GPU/Common/FramebufferManagerCommon.cpp Outdated Show resolved Hide resolved
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)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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]

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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]

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, that makes sense. I'll revise the comment.

@hrydgard hrydgard force-pushed the framebuffer-sequence-numbers branch from e0463cb to 078fc88 Compare August 17, 2022 08:15
@hrydgard hrydgard merged commit 9498ff1 into master Aug 17, 2022
@hrydgard hrydgard deleted the framebuffer-sequence-numbers branch August 17, 2022 08:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Code Cleanup Cleanup to make future work easier. Needs to be done sometimes. GE emulation Backend-independent GPU issues
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants