vkQueueSubmit frozen when the commad buffer contains vkCmdCopyImage

[Graou74]

Hello,

I have the Vulkan part of my application based on the official Vulkan tutorial. It perfectly displays 3D objects and camera movements.

I tried to image copy by doing my best to transcribe as best as possible the example of Sacha Willems, the saveScreenshot () function of the source screenshot.cpp. I use LWJGL as my code is in java, on MacOs and Vulkan version 1.1.130.0.

Before transcribing the whole function, I wanted to test the absence of error. What is implemented is:

1. Recovery of the source image from the swapchain.
2. Creation of the destination image.
3. Memory allocation of the destination image.
4. Creation and start of the command buffer.
5. insertion of ImageMemoryBarrier before invoking the copy.
6. Invoking the copy (vkCmdCopyImage).
7. insertion of ImageMemoryBarrier after the invocation of the copy.
8. End and submit the buffer command.

At runtime, the application freezes when called vkQueueSubmit () and no error is reported since the extension of debug Vulkan.

If the call to vkCmdCopyImage () is commented out, the copy is obviously not made but the application no longer hangs and still no Vulkan error is reported.

I checked each part of code several times and since Vulkan does not report any anomalies, I do not know where to look for a solution.

I wonder if the problem would not come from the source image of the swapchain but I do not see how I could verify this.

Thanks for your help.

[Sascha_Willems]

If your application freezes (usually for a short timeframe as the TDR kicks in) you’re usually doing something so wrong that the driver can’t handle it. I expect you have used the validation layers to verify that api usage is okay so far, but you could still run into hardware limitations or do something wrong where the layers are lacking like layout transitions. Also make sure that the image you’re copying from actually supports the TRANSFER_SRC flag and that that flag is set.

Also note that on MacOS you’re using MoltenVK as a translation layer, which in itself may bring some additional limitations that your GPU doesn’t have.

But without any actual code it’s hard to help.

[Graou74]

@Sascha_Willems

I expect you have used the validation layers to verify that api usage is okay

Yes and it has helped me so far but in the specific case, everything seems ok since nothing is reported.

@Sascha_Willems

Also make sure that the image you’re copying from actually supports the TRANSFER_SRC flag and that that flag is set.

As the source image comes from the swapchain, I have positioned VK_IMAGE_USAGE_TRANSFER_SRC_BIT when creating the structure VkSwapchainCreateInfoKHR (info precisely brought up by the validation layers):

VkSwapchainCreateInfoKHR swapchainCI = VkSwapchainCreateInfoKHR.calloc()
        .sType(VK_STRUCTURE_TYPE_SWAPCHAIN_CREATE_INFO_KHR)
        .surface(surface)
        .minImageCount(desiredNumberOfSwapchainImages)
        .imageFormat(colorFormat)
        .imageColorSpace(colorSpace)
        .imageUsage(VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT | VK_IMAGE_USAGE_TRANSFER_SRC_BIT)
        .preTransform(preTransform)
        .imageArrayLayers(1)
        .imageSharingMode(VK_SHARING_MODE_EXCLUSIVE)
        .presentMode(scp.swapchainPresentMode)
        .oldSwapchain(oldSwapChain)
        .clipped(true)
        .compositeAlpha(VK_COMPOSITE_ALPHA_OPAQUE_BIT_KHR);

I imagine this is the TRANSFER_SRC you are talking about. On the other hand I did not check if it was supported. It will be my priority.

@Sascha_Willems

Also note that on MacOS you’re using MoltenVK as a translation layer, which in itself may bring some additional limitations that your GPU doesn’t have.

Hopefully this is not the case, my graphics card is a Radeon Pro 580 8 GB.

@Sascha_Willems

But without any actual code it’s hard to help.

Yes it is obvious. If I can’t find it with the track you gave me I would provide the code.

Thank you for your quick intervention.

[Graou74]

Phew, I found it.

Well, the function is not finished but it no longer freezes.

I have to verify that TRANSFER_SRC is supported and it is the case therefore it is a track to be discarded. But by wanting to show the code of this test function, for a possible correction, I added a comparison between the format of the source image and that of the destination image being convinced that it would return true. But it returned false and the problem came from there.

The format of the source image was VK_FORMAT_B8G8R8A8_UNORM while that of the destination image was VK_FORMAT_R8G8B8A8_UNORM.
By checking the code I was convinced that it was the same value because the resemblance is tricky. But they won’t take me anymore.

Thank you Mr. Willems for your intervention but also for your many examples which are of great help.

[Graou74]

@Sascha_Willems

Also note that on MacOS you’re using MoltenVK as a translation layer, which in itself may bring some additional limitations that your GPU doesn’t have.

This is probably a problem of this type.
After solving the frozen application problem, all image copy processing was error free but my image remained black.

So I decided to do the test on PC and there I get the expected copy.

In conclusion, the copy with vkCmdCopyImage, on Macos, with correct code, freezes (VK_FORMAT_R8G8B8A8_UNORM is the good value but Macos does not support this copy).

I guess I can make a ticket to MoltenVK to let them know.
As I need the image copy I will now try vkCmdCopyImageToBuffer hoping it will work.

If someone has a safer alternative I am interested.