Vulkan: Raise number of command buffers #11090
Conversation
K0bin
force-pushed
the
submit-rework
branch
from
90bef69
to
c9002ed
Compare
K0bin
force-pushed
the
submit-rework
branch
from
c9002ed
to
e727dae
Compare
K0bin
force-pushed
the
submit-rework
branch
from
e727dae
to
f9700ba
Compare
|
Can you split the |
|
I looked at this the other night and thought this looked good overall. From glancing it over, it seems like there shouldn't be any issues but I plan on doing some testing tonight since we can't count on fifoci for these changes. |
|
I'll try to split them up. |
…cessary We only need to synchronize with the submission thread when submitting on the GPU thread or when waiting for a command buffer.
Avoid waiting for earlier submissions when we flush more often. The vertex manager will flush more often if the game accesses the EFB on the CPU, to give the GPU a head start.
K0bin
force-pushed
the
submit-rework
branch
from
f9700ba
to
e5fb9c9
Compare
|
Seems to work, though I haven't combined it with other PRs to see the full potential. |
|
I didn't look especially hard, but what's preventing a third frame from starting when two frames are queued, making a descriptor pool get reset before the GPU is done with it? |
In order to keep the GPU busy when Dolphin does EFB readbacks, there's the option to automatically flush the command buffer at specific points instead of just before a readback or at the end of the frame.
The problem with this is that Dolphin currently only has 2 Vulkan command buffers and when both of those are in use, it will just wait for one to become available. So flushing more often could make CPU-GPU parallelism worse if the GPU didn't finish the command buffers faster than Dolphin was flushing.
My Snapdragon 865 phone sits at <30% GPU utilization with Mario Galaxy (1x res) while the CPU spends most of its time waiting for the CPU to finish. So flushing more often is definitely beneficial because it allows the GPU to start working sooner.
This PR raises the number of command buffers to 8. We could easily use a higher number here but 8 seems fine in my very limited testing. Mario Galaxy for example uses ~22 command buffers but 8 is enough here because it stalls before exceeding 8, so we can just reuse the earlier ones.
Dolphins VkDescriptorPools are huge, so I've separated those from the command buffer. The number of VkDescriptorPools is still 2 and they are associated with a frame rather than a command buffer.
I've also tweaked the synchronization logic with the submission thread. Before, it would sync on every submission, now it only syncs on submits which need to finish immediately.