pcsx2
pcsx2 copied to clipboard
GS/Vulkan: Split command buffer submission and presentation
Description of Changes
Attempting to further improve frame pacing. The current frame times are a bit of a lie with Vulkan, because it's the time the GS thread kicked it to the submit thread, not after the frame actually finished being queued.
This gives us a window of time where we can potentially do some per-frame readbacks as well.
It can potentially improve performance too in GPU-bound scenarios, where the time to render the frame varies from frame to frame, since we're submitting 16ms - EE_TIME
earlier than we otherwise would have.
Currently only implemented in Vulkan, but it's possible in DX12 too (and Metal, but I lack hardware).
Rationale behind Changes
Improving frame pacing.
Suggested Testing Steps
See if there's any differences with frame timing/pacing, possibly try with externals too, PCSX2's readings should be fairly close now.
Present timing on NVIDIA is apparently all over the place.... https://forums.developer.nvidia.com/t/presentkhr-still-blocks-on-windows-even-when-using-vk-khr-present-wait/251142 sounds like we might be experiencing the same thing.
Intel on Windows is rock solid.
Tested with Dragon Quest VIII that showed quite an uneven framepacing.
Master
PR
Looks about the same to me, tbh
Readbacks/downloads which sync the EE/GS threads are going to have inconsistent frame times, it's pretty much unavoidable.
Tested with Crash Twinsanity, the framepacing became a little bit uneven but overall nothing bad happens, and imo the difference isn't noticeable.
Master:
PR:
Tested with Crash Twinsanity, the framepacing became a little bit uneven but overall nothing bad happens, and imo the difference isn't noticeable.
The reported time before was a lie, it wasn't including vkQueuePresentKHR (since it happens on the submit thread. I'd bet you'd see the same wonkyness if you turned off async presentation.
The numbers now are accurate regardless of whether async is used.
That's good to know!