Vulkan device lost when writing to the swapchain from a sampled texture

[isenao]

Hello,

I am currently developing a Qt based application using Vulkan and dynamic rendering. The program renders two cubes to a 32bit floating point texture and then samples that texture on a full screen quad to be presented on the swapchain. I've ran this code on a NVIDIA RTX 4060 and had no issues but when executing it in my i7-12700 with a UHD Graphics 770 after submitting the command buffer the device is lost. There are no validation layer errors and it doesn't seem like a synchronization problem since I've tried inserting barriers between render passes and calling vkDeviceWaitIdle between vkQueueSubmit and vkQueuePresentKHR. Also, the issue only happens when setting the output of the fragment shader to the sampled value (if I sample the texture but don't use the value and write some constant value to the output there is no issue). I've updated my drivers to the last available version and tried running the program in other systems and it still happens.  

I attach the logs generated by the crash diagnostic layer but since my device doesn't support certain extensions they might not be perfectly accurate. 

System info:

OS: Microsoft Windows 11 Pro

CPU: 12th Gen Intel(R) Core(TM) i7-12700, 2100 Mhz 

GPU: Intel(R) UHD Graphics 770

Driver Version: 32.0.101.6913

Program info:

Qt Version 6.8.2

Vulkan version 1.3

Vulkan SDK 1.4.309.0

Enabled extensions: VK_KHR_dynamic_rendering, VK_KHR_swapchain

Libraries in use: glm, Vulkan Memory Allocator

[isenao]

I have tried replicating the issue in another environment and its still happening. I redid the program using GLFW and Visual Studio 2022 instead of Qt and the same happens: works perfectly in my 4060 but the device is lost in my iGPU after submitting. One weird thing I have noticed is that when running it on my other GPU using RenderDoc, the first three frames are black in the thumbnails while inspecting the vkQueuePresentKHR command shows that the texture is filled. 

[isenao]

Ok so I figured out what was happening. The issue was that I was updating my descriptor sets during my render pass. It seems that the descriptor sets where not properly updated and I was accessing "garbage" memory. Calling vkUpdateDescriptorSets before my render loop fixed the issue.