Do i really need for each image in a swapchain its own descriptorset and coresponding buffers?

So question is:
Do I really need for each image in a swapchain its own descriptorSet and corresponding buffers if they are modified each frame and I didn’t wait at the end of draw loop?

This question arise from tutorials what I see around internet.

In most popular tutorial from here https://github.com/Overv/VulkanTutorial/blob/master/code/22_descriptor_sets.cpp author uses multiple descriptorSets.

But for tutorial from nvidia or intel, it seams they aren’t multiply that objects by swapchain image count, and aquire-submit-present loop looks also like in the example above, without waiting at the end of loop for work done. And generally I can’t find any other examples of vulkan code where descriptorSets created for each swapchain image or frame in flight.

So I’m a little bit confusing. Also in my experiments with FIFO mode just one descriptorSet modified each frame seems work fine, even if I start modified underlying buffer and record next cb without waiting for present.

Driving without a seatbelt also “seems [to] work fine” too, right until it doesn’t.

Your validation layers should not allow you to modify a descriptor set that is in use. So unless you do something that forces a sycnhronization, they should complain.

Yep, that’s why I’m here.

Well I didn’t do any crazy stuff with it, just bind, and memcpy my changing data to underlying buffer each frame, validation layers didn’t complain about that, synchronization between submits similar to the one in tutorial that i mentioned, just use instead of one descriptorSet per frame in flight, only one object for all of them.

That’s because they can’t. You said you were changing the descriptor sets, not the resources accessed through the descriptor sets.

It’s undefined behavior either way, but validation layers can only see what the Vulkan API shows them. Modifications to mapped pointers cannot be seen, so they can’t be validated.

1 Like