Remove synchronization necessity for logically independent FFTs

[CoffeeExterminator]

Hi!
I was trying to run multiple ffts simultaneously using the same VkFFT application and different input/main buffers by recording and submitting command buffers with different launch params one after another without waiting for the previous submit to complete. However, this seems to be impossible, and I got the following validation error:

Validation Error: [ VUID-vkUpdateDescriptorSets-None-03047 ] Object 0: handle = 0x7f79ad0000000050, type = VK_OBJECT_TYPE_DESCRIPTOR_SET; Object 1: handle = 0x7cd292000000004f, type = VK_OBJECT_TYPE_DESCRIPTOR_SET_LAYOUT; | MessageID = 0x35d7ea98 | vkUpdateDescriptorSets(): pDescriptorWrites[0].dstBinding (0) was created with VkDescriptorBindingFlags(0), but VkDescriptorSet 0x7f79ad0000000050[] is in use by VkCommandBuffer 0x589bad0[]. The Vulkan spec states: Descriptor bindings updated by this command which were created without the VK_DESCRIPTOR_BINDING_UPDATE_AFTER_BIND_BIT or VK_DESCRIPTOR_BINDING_UPDATE_UNUSED_WHILE_PENDING_BIT bits set must not be used by any command that was recorded to a command buffer which is in the pending state (https://vulkan.lunarg.com/doc/view/1.3.268.0/linux/1.3-extensions/vkspec.html#VUID-vkUpdateDescriptorSets-None-03047)

I suppose the reason behind this is using the same descriptor set for each append, which results in said set being modified by the current append while being used by the previous submit, even though logically these ffts are independent. I haven't seen the requirement for synchronization of such independent fft executions mentioned in documentation, so it could be useful to add it there or, perhaps, remove the need for such synchronization (since it is an important issue in terms of performance in some cases).

[DTolm]

Hello,

I believe the solution you are looking for is using push descriptors (#155).

Best regards,
Dmitrii

[CoffeeExterminator]

Hi,
I have tested push descriptors and it looks like what I needed, thank you very much.
However, I have encountered the following validation error:

vkCmdDispatch():  The VkPipeline 0x9f1516000000008c[] (created with VkPipelineLayout 0xde4e51000000008b[]) statically uses descriptor set (index #0) which is not compatible with the currently bound descriptor set's pipeline layout (VkPipelineLayout 0x0[]). The Vulkan spec states: For each set n that is statically used by a bound shader, a descriptor set must have been bound to n at the same pipeline bind point, with a VkPipelineLayout that is compatible for set n, with the VkPipelineLayout or VkDescriptorSetLayout array that was used to create the current VkPipeline or VkShaderEXT, as described in Pipeline Layout Compatibility (https://vulkan.lunarg.com/doc/view/1.3.268.0/linux/1.3-extensions/vkspec.html#VUID-vkCmdDispatch-None-08600)

It seems to me the reason is that currently the assumption with push descriptors is that the command buffer remains the same for all append calls. And thus, if the command buffer changes (the input and output buffers remain the same in my case), vkCmdPushDescriptorSetKHR is not called for the new buffer to bind/update descriptor sets.

I tried modifying the code to check for command buffer change and modify performBufferSetUpdate accordingly before VkFFTUpdateBufferSet to test my hypothesis, and it seemed to solve the problem, but I don't feel very confident about it still.