Potential infinite loop and missing error handling in Vulkan backend (vkAcquireNextImageKHR) #14250
Description
Hi SDL team,
While reviewing the Vulkan backend implementation in the SDL3 GPU API, I noticed a potential performance and stability issue in the image acquisition logic using vkAcquireNextImageKHR. Here's the relevant code snippet:
while (true) {
acquireResult = renderer->vkAcquireNextImageKHR(
renderer->logicalDevice,
windowData->swapchain,
SDL_MAX_UINT64,
windowData->imageAvailableSemaphore[windowData->frameCounter],
VK_NULL_HANDLE,
&swapchainImageIndex);
if (acquireResult == VK_SUCCESS || acquireResult == VK_SUBOPTIMAL_KHR) {
break;
}
Uint32 recreateSwapchainResult = VULKAN_INTERNAL_RecreateSwapchain(renderer, windowData);
if (!recreateSwapchainResult) {
return false;
} else if (recreateSwapchainResult == VULKAN_INTERNAL_TRY_AGAIN) {
return true;
}
}
Potential issues:
Infinite loop risk: If vkAcquireNextImageKHR repeatedly returns an unexpected error, this loop could run indefinitely without delay or exit condition.
Missing error handling: Common Vulkan return codes like VK_ERROR_OUT_OF_DATE_KHR or VK_ERROR_SURFACE_LOST_KHR are not explicitly handled, which could lead to incorrect behavior or missed recovery opportunities.
No retry limit or backoff: Repeated swapchain recreation without a cap or delay could cause high CPU usage or resource churn.
No logging: Failures in image acquisition or swapchain recreation are not logged, making debugging difficult.
Suggestions:
Add a maximum retry count or timeout to prevent infinite loops.
Explicitly handle known Vulkan error codes.
Consider adding a small delay or exponential backoff between retries.
Log acquisition and recreation failures for better diagnostics.
RenderDoc Capture:
Thanks for your hard work on SDL!