Hello! We have faced the crash which I described in the “steps to reproduce” section, after moving from 5.3 to 5.5 We found out that it happens because the engine tries to bind VulkanBackBuffer texture to SampledImage descriptor slot, but the texture (FVulkanBackBuffer) doesn’t have VK_IMAGE_USAGE_SAMPLED_BIT set, so the code goes through the StorageImage branch, see VulkanPipelineState.h#L73.
The root of the issue is that, even though the Swapchain is create with ImageUsageFlags containing VK_IMAGE_USAGE_SAMPLED_BIT (see VulkanSwapChain.cpp#L488), and BackBufferImages also have it, FVulkanBackBuffer has ImageUsageFlags equal to 0. That happens because it doesn’t have VkImage, so the following branch in the FVulkanTexture constructor is not executed, see VulkanTexture.cpp#L1636
So my questions are:
- Is there a chance that it’s already fix in UE5.6 or in the main branch so you could share the CL we can apply
- If not, could you please validate if simply adding the set of ImageUsageFlags which are used for Swapchain creation, and which includes VK_IMAGE_USAGE_SAMPLED_BIT to FVulkanBackBuffer, either in its constructor or right after an object creation, is a good solution?
Steps to Reproduce
Steps:
- Set r.Vulkan.DelayAcquireBackBuffer=0 in the project
- On Vulkan Execute downscaling pass which is using BackBuffer as an input
Actual Result:
Hi,
Something of note is that there is the following comment from commit 6deae8a:
‘Switch android vulkan to delay acquire back buffer to avoid a crash during backgrounding’.
With the following .ini lines commented out
; acquire next image on frame start - disabled see FORT-537665
; +CVars=r.Vulkan.DelayAcquireBackBuffer=0
This is still in place on UE-Main which may indicate that a fix has not been put in place.
I have been unable to reproduce the issue using the provided steps. Are you able to send through a minimal project that reproduces the issue and/or expand on the downscaling technique you are using and the intention behind setting the DelayAcquireBackBuffer to acquire the image at the start of the frame.
Once the issue can be reproduced we can look at fixes, alternate options and if necessary, issue a bug report.
Hello Tristan,
Unfortunately, I don’t have the capacity to try reproducing it in a sample project.
It seems that the issue is in the code, and I’ve already found the fix which works for us.
I just wanted to highlight the problem and the fix, so that a developer can validate it and include it in the next release if it’s a good solution.
Kind regards
Hi,
I have attempted to reproduce the issue described using the following steps:
- Create a project using the Top Down Template
- Disable OpenGLES support in the Project settings
- Enable Vulkan Support in the Project Settings
- Add the following console variables in the start up section of Engine/Config/ConsoleVariables.ini to attempt to trigger rendering actions using the back buffer
- r.Vulkan.DelayAcquireBackBuffer=0
- r.ScreenPercentage=60
- r.TemporalAA.Upsampling=1
- Package for Android in Development mode
- Run the packaged application on device
While exploring the map on the device no crash was presented. Are there any additional steps that I can add to the testing process on my end to support triggering the issue you describe.
It is important to be able to reliably trigger the issue to verify that the issue is not localized to your project and can be accurately inspected by the engineer who will assess any bug reports.
Some possible next steps:
- Supply additional testing information
- Verify that the steps you have provided reliably trigger the issue in a blank project