Modify virtual swapchain behavior #1222
Conversation
MarkY-LunarG
requested review from
locke-lunarg,
bradgrantham-lunarg,
panos-lunarg and
andrew-lunarg
|
CI gfxreconstruct build queued with queue ID 20859. |
|
CI gfxreconstruct build # 3069 running. |
|
CI gfxreconstruct build # 3069 failed. |
|
CI gfxreconstruct build queued with queue ID 21383. |
|
CI gfxreconstruct build # 3072 running. |
|
CI gfxreconstruct build # 3072 failed. |
|
CI gfxreconstruct build queued with queue ID 21423. |
|
CI gfxreconstruct build # 3073 running. |
|
CI gfxreconstruct build # 3073 failed. |
|
CI gfxreconstruct build queued with queue ID 21511. |
|
CI gfxreconstruct build # 3074 running. |
|
CI gfxreconstruct build # 3074 failed. |
|
CI gfxreconstruct build queued with queue ID 21990. |
|
CI gfxreconstruct build # 3075 running. |
|
CI gfxreconstruct build queued with queue ID 22027. |
|
CI gfxreconstruct build # 3076 running. |
|
Moved to draft because I can't figure out why it's failing on internal CI systems yet. I'll move it back when that runs clean. |
|
CI gfxreconstruct build # 3076 failed. |
|
CI gfxreconstruct build queued with queue ID 22116. |
|
CI gfxreconstruct build # 3077 running. |
|
CI gfxreconstruct build queued with queue ID 22136. |
|
CI gfxreconstruct build # 3078 running. |
|
CI gfxreconstruct build # 3078 failed. |
|
CI gfxreconstruct build # 3121 passed. |
MarkY-LunarG
force-pushed
the
marky_fix_screenshot_wait
branch
from
a3ea9b3 to
1a28b3a
Compare
|
CI gfxreconstruct build queued with queue ID 30775. |
|
CI gfxreconstruct build # 3138 running. |
|
CI gfxreconstruct build # 3138 passed. |
|
CI gfxreconstruct build queued with queue ID 30883. |
|
CI gfxreconstruct build # 3139 running. |
|
CI gfxreconstruct build # 3139 passed. |
|
@bradgrantham-lunarg , does everything look good to you? Locke approved this but I don't want to push it prematurely. |
| struct SwapchainData | ||
| { | ||
| // Create a map that correlates copy command data with a queue family index. | ||
| std::map<size_t, CopyCmdData> copy_cmd_data; |
There was a problem hiding this comment.
Since vkGetPhysicalDeviceQueueFamilyProperties takes and modifies a uint32_t, can this be a std::map on a uint32_t? For that matter, since it's just on an integer key, can this be a std::unordered_map?
There was a problem hiding this comment.
std::map is faster. especially if the items are ordered, which they are. That's why I used map.
There was a problem hiding this comment.
unordered_map uses hashes and is O(1).
There was a problem hiding this comment.
After discussion, Brad showed me that std::map is slower than std::unordered_map on average. Switched.
Modify virtual swapchain to create a command buffer per queue and and per swapchain image. Then when a vkQueuePresent occurs, perform the blits in the same queue as the presented queue to reduce race conditions. This resolves the issue where a QueuePresent is presented inline in a queue, but has no wait semaphore information. Instead, the QueuePresent relied upon the previous submit (also in the same queue) to perform the synchronization. Previously, the virtual swapchain had it's own Queue that it used which caused a race condition resulting in old images being used. Fixes: LunarG#1122
Move data that is only ever used by the VulkanVirtualSwapchain class into private members of that class. Everything is now accessed via a pointer to the PrivateData struct which is associated with the VkSwapchainKHR handle in an unordered_map.
Thanks to @locke-lunarg for discovering validation message warnings introduced by my last set of changes. This fixes all the new validation error messages introduced at least in the VkCube example.
Fixed an error that popped up on Windows Nvidia 32-bit
MarkY-LunarG
force-pushed
the
marky_fix_screenshot_wait
branch
from
be88125 to
ceb3baf
Compare
|
CI gfxreconstruct build queued with queue ID 32867. |
|
CI gfxreconstruct build # 3146 running. |
|
CI gfxreconstruct build queued with queue ID 32900. |
Modify virtual swapchain to create a command buffer per queue and when we get a vkQueuePresent, perform the blits in the same queue. This resolves the issue where a QueuePresent is presented inline in a queue, but has no wait semaphore information. Instead, the QueuePresent relied upon the previous submit (also in the same queue) to perform the synchronization.
Previously, the virtual swapchain had it's own Queue that it used which caused a race condition resulting in old images being used.
Also, instead of doing just a waitforidle, wait for all pending semaphores (which could include some that are pending but not submitted).
Also, don't wait for idle after the screenshot submit, wait for the fence. This way we don't have to keep idling the GPU.
Fixes: #1122