Can vkQueuePresentKHR be synced using a pipeline barrier?

There are couple of outstanding Issues against the specification. Notably KhronosGroup/Vulkan-Docs#1308 is exactly your question.

Meanwhile everyone usually follows this language:

The processing of the presentation happens in issue order with other queue operations, but semaphores have to be used to ensure that prior rendering and other commands in the specified queue complete before the presentation begins.

Which implies semaphore has to be used. And given we are not 110 % sure, that means semaphore should be used until we know any better.

Another semi-official source is the sync wiki, which uses a semaphore.

Despite what this quote says, I think it is reasonable to believe it is also permissible to use other sync that makes the image already visible before the vkQueuePresent, such as fence wait.

But just pipeline barriers are likely not sufficient. The presentation is outside the queue system:

However, the scope of this set of queue operations does not include the actual processing of the image by the presentation engine.

Additionally there is no VkPipelineStageFlagBit for it, and vkQueuePresentKHR is not included in the submission order, so it cannot be in the synchronization scope of any vkCmdPipelineBarrier.

The confusing part is this unfortunate wording:

Any writes to memory backing the images referenced by the pImageIndices and pSwapchains members of pPresentInfo, that are available before vkQueuePresentKHR is executed, are automatically made visible to the read access performed by the presentation engine.

I believe the trick is the "before vkQueuePresentKHR is executed". As said above, vkQueuePresentKHR is not part of submission order, therefore you do not know if the memory was or wasn't made available via a pipeline barrier before the vkQueuePresentKHR is executed.

Presentation is a queue operation. That's why you submit it to a queue. A queue that will execute the presentation of the image. And specifically to a queue that is able to perform present operations.

As for how to synchronize... the specification is a bit ambiguous on this point.

Semaphores are definitely able to work; there's a specific callout for this:

Semaphores are not necessary for making the results of prior commands visible to the present:

Any writes to memory backing the images referenced by the pImageIndices and pSwapchains members of pPresentInfo, that are available before vkQueuePresentKHR is executed, are automatically made visible to the read access performed by the presentation engine. This automatic visibility operation for an image happens-after the semaphore signal operation, and happens-before the presentation engine accesses the image.

While provisions are made for semaphores, there is no specific statement of other things. In particular, if you don't wait on a semaphore, it's not clear what "happens-after the semaphore signal operation" means, since no such signal operation happened.

Now, the API for vkQueuePresentKHR makes it clear that you don't need to provide a semaphore to wait on:

waitSemaphoreCount is the number of semaphores to wait for before issuing the present request.

The number may be zero.

One might thing that, as a queue operation, all prior synchronization on that queue would still affect presentation. For example, an external subpass dependency if you wrote to the swapchain image as an attachment. And it probably would... if not for one little problem.

See, synchronization is ultimately based on dependencies between stages. And presentation... doesn't have a stage. So while your source for the external dependency would be well-understood, it's not clear what destination stage would work. Even specifying the all-stages flag wouldn't necessarily work.

Does "not a stage" exist in the set of all stages?

In any case, it's best to just use a semaphore. You'll probably need one anyway, so just use that.