GS:VK: Migrate to VK 1.3 and use dynamic rendering. - #14787
Conversation
009e64b to
a522289
Compare
|
This PR brings a massive FPS boost when GPU bound. For example, running Soulcalibur III at 5x internal resolution on a 780M: master gets 41.5 FPS, while this PR hits 52.0 FPS. |
| vkGetPhysicalDeviceProperties(device, &props); | ||
| VkPhysicalDeviceProperties2 props2 = { VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PROPERTIES_2 }; | ||
| vkGetPhysicalDeviceProperties2(device, &props2); | ||
| VkPhysicalDeviceProperties props = props2.properties; |
There was a problem hiding this comment.
| VkPhysicalDeviceProperties props = props2.properties; | |
| const VkPhysicalDeviceProperties& props = props2.properties; |
| semaphore_signal_info[0] = { VK_STRUCTURE_TYPE_SEMAPHORE_SUBMIT_INFO, nullptr, | ||
| present_swap_chain->GetRenderingFinishedSemaphore(), 0, VK_PIPELINE_STAGE_2_ALL_COMMANDS_BIT, 0 }; | ||
| semaphore_signal_info[1] = { VK_STRUCTURE_TYPE_SEMAPHORE_SUBMIT_INFO, nullptr, | ||
| m_spin_resources[m_current_frame].semaphore, 0, VK_PIPELINE_STAGE_2_ALL_COMMANDS_BIT, 0 }, |
There was a problem hiding this comment.
Personally I'm not a huge fan of doing this with Vulkan, though I realize we do plenty in the rest of GSDeviceVK.
I'd much prefer
semaphore_signal_info[0] = { VK_STRUCTURE_TYPE_SEMAPHORE_SUBMIT_INFO };
semaphore_signal_info[0].whatever0 = present_swap_chain->GetRenderingFinishedSemaphore();
semaphore_signal_info[0].whatever1 = VK_PIPELINE_STAGE_2_ALL_COMMANDS_BIT;(And if those 0s are important, set them explicitly. If they're not, don't.)
There was a problem hiding this comment.
I changed this to use a named initializer list, as it's slightly more compact:
semaphore_signal_info[0] = { .sType = VK_STRUCTURE_TYPE_SEMAPHORE_SUBMIT_INFO,
.semphore = present_swap_chain->GetRenderingFinishedSemaphore(),
.stageMask = VK_PIPELINE_STAGE_2_ALL_COMMANDS_BIT };
| vkCmdPipelineBarrier(resources.command_buffer, VK_PIPELINE_STAGE_TRANSFER_BIT, | ||
| VK_PIPELINE_STAGE_COMPUTE_SHADER_BIT, 0, 0, nullptr, 1, &barrier, 0, nullptr); | ||
|
|
||
| const VkBufferMemoryBarrier2 barrier{ VK_STRUCTURE_TYPE_BUFFER_MEMORY_BARRIER_2, nullptr, |
883d67b to
37de3c2
Compare
|
Added a separate commit that changes all VK structs with a structure type member ( |
|
I've been thinking about this and it's probably best keeping dynamic rendering as optional without migrating to VK 1.3. |
Sure, there's not an overwhelming reason to use 1.3 yet. |
|
I think requiring vk1.3 is fair , every gpu in the past 10 years have support for it , if you have kepler gpu you can use a stable build and upgrade it , the ram crisis isnt of our making |
|
Also if you can't afford a new gpu because of the ram crisis, you're not buying a kepler, you will at least get a maxwell which will cost you similar to a McDonald's for two people. If you're going to use 14 year old hardware, you can use old software that supports it |
|
Gotta agree on this one. Kepler is ancient GPU and honestly, an used rx6600 (or the nvidia equivalent) in the used market shouldn't be too bad. |
AmandaRoseChaqueta
left a comment
AmandaRoseChaqueta
left a comment
There was a problem hiding this comment.
Tested a couple of gs dumps and games, couldn't see any issues or regressions on linux.
|
Ditto, Kepler is just simply too old at this point. |
Use synchronization2, renderpass2, and others. Rewrite the VK render pass builder.
37de3c2 to
0204fd8
Compare
Only used if both dynamic rendering and dynamic local read are available.
Remove one redundant level of flags and use an enum class with overloaded bitwise operators.
0204fd8 to
d9886d9
Compare
10 participants
Description of Changes
Migrate to VK 1.3 (basically use the commands and enums that end in '2' like vkCmdPipelineBarrier2, etc.)
Use dynamic rendering if it's supported, otherwise use traditional render passes.
Some cleanup to remove redundancy in feedback loop flags introduced in #13631.
Use name initializer lists for constructing VK structs.
Rationale behind Changes
Main rationale is that we're using VK 1.3 in #14737, so this is to avoid using deprecated functionality. However, most of the updates should be semantically identical.
Anticipate moving to 1.4 and using only dynamic rendering and removing the traditional render passes/frame buffers.
Code clarity.
Suggested Testing Steps
Test VK to make sure it still works correctly. Everything should be identical to master.
@JordanTheToaster noticed slightly higher CPU usage, so that needs to be looked into.
The first (VK 1.3) and last commits (dynamic rendering + feedback loop flags cleanup) have been dump run.
Did you use AI to help find, test, or implement this issue or feature?
Likely at some point to ask about API usage, semantics, etc.