Blank screens and VK_SUBOPTIMAL_KHR swapchain results can occur on macOS and iOS following swapchain recreation when either image_count, image_usage_flags, or transform parameters are changed without changing the swapchain extent. This issue manifests itself when activating options for the following samples: afbc, msaa, _swapchainimages, _hpp_swapchainimages, and _surfacerotation.
I am not sure why this happens, but it may have something to do with MoltenVK's possible reuse of swapchain image and/or imageview resources, and the mechanism that Vulkan Samples uses when managing those resources on recreation. If the swapchain extent is changed (i.e. resized), then recreation happens correctly and blank screens do not occur. Alternatively, this may be a defect in MoltenVK or somewhere else.
There is a workaround to avoid this problem: recreate the swapchain in [HPP]RenderContext::begin_frame() specifically in cases when vkAcquireNextImageKHR() returns VK_SUBOPTIMAL_KHR following swapchain parameter updates. I will push a PR that implements this change for Apple devices only.
However, it would be good to get feedback from @billhollings and @gpx1000 regarding the root cause of the problem, or if this is expected behaviour with MoltenVK.
Blank screens and
VK_SUBOPTIMAL_KHRswapchain results can occur on macOS and iOS following swapchain recreation when eitherimage_count,image_usage_flags, ortransformparameters are changed without changing the swapchain extent. This issue manifests itself when activating options for the following samples: afbc, msaa, _swapchainimages, _hpp_swapchainimages, and _surfacerotation.I am not sure why this happens, but it may have something to do with MoltenVK's possible reuse of swapchain image and/or imageview resources, and the mechanism that Vulkan Samples uses when managing those resources on recreation. If the swapchain extent is changed (i.e. resized), then recreation happens correctly and blank screens do not occur. Alternatively, this may be a defect in MoltenVK or somewhere else.
There is a workaround to avoid this problem: recreate the swapchain in
[HPP]RenderContext::begin_frame()specifically in cases whenvkAcquireNextImageKHR()returnsVK_SUBOPTIMAL_KHRfollowing swapchain parameter updates. I will push a PR that implements this change for Apple devices only.However, it would be good to get feedback from @billhollings and @gpx1000 regarding the root cause of the problem, or if this is expected behaviour with MoltenVK.