Hi,

I am trying to fix an issue I am seeing with my engine using Vulkan. I tested my code on 2 pcs and on one of them with debug build I get flicker while moving the camera which seems to be caused by accessing wrong constant buffer values. Considering it doesn't happen with both pcs and release build makes me believe that it is a synchronization issue. That said I made some tests which proved otherwise. 

To give some details about my code, I have rendering setup in a way that cpu can record up to 3 frames ahead of the gpu and then I wait with a fence. So all the resources are tripled and I access the proper one for each frame. Currently for my test case I have 3 render threads, each having their own command buffer. First thread just does vkCmdUpdateBuffer on the buffers that will be used for other command buffers. I have pipeline barriers with srcAccessMask = VK_ACCESS_TRANSFER_WRITE_BIT and dstAccessMask = VK_ACCESS_UNIFORM_READ_BIT for each update(for now) to make sure it works. Second thread fills the command buffer for gbuffer rendering. And last thread fills the command buffer for lighting. At the beginning of the lighting command buffer there is a pipeline barrier with VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT, VK_ACCESS_SHADER_READ_BIT, VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL, VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL to make sure all writes to it finished. And after light draw I just convert the gbuffer render targets their old format using VK_ACCESS_SHADER_READ_BIT, VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT, VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL, VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL. Once all the threads are done I submit each command buffer individually(I will get to this in a little bit), with the order I mentioned. 1-Update command buffer 2-Gbuffer command buffer 3-Light command buffer.

So from what I understand from Vulkan docs pipeline barriers are creating dependency in the commands given to a single queue. So it shouldn't matter which command buffer does the barrier. In my case for example, using the buffer barrier with srcAccessMask = VK_ACCESS_TRANSFER_WRITE_BIT,  dstAccessMask = VK_ACCESS_UNIFORM_READ_BIT should make that buffer available for uniform read in the future commands even if they were in another command buffer. So to find the issue tried bunch of stuff. First tried getting capture with renderdoc but I couldn't reproduce the issue when I run my app with renderdoc. Seems like it is forcing the command to happen linearly. I am not sure if there are any other tool that does similar thing. Then I tried using vkQueueWaitIdle which solved the issue as I was expecting. And I kept the most interesting to the last :). Instead of submitting the command buffers individually, if I submit as batch with VkSubmitInfo.commandBufferCount = 3, I don't see the issue happening anymore. Also in a similar fashion instead of using separate command buffers with their own Begin and End, if I use 1 command buffer and just fill that command buffer with these commands in the order I mentioned, again I don't see the issue. 

Thanks in advance.

Further update this. I tried using semaphores so that each command buffer waits for the previous one and that worked fine which I was already expecting it to work. So for anyone that doesn't want to read the whole thing, the question is that do pipeline barriers work between multiple command buffers. For example I have command buffer A and command buffer B. A has some buffer updates and global memory barrier with src=BOTTOM_OF_PIPE and dest=TOP_OF_PIPE, and B has draw commands using those buffers. If I do vkQueueSubmit(A) and vkQueueSubmit(B), is it supposed to make all the commands on B wait for global memory barrier?