If I understand it properly, the calls to vkQueueSubmit are order depended and the submitted command buffer execution works FIFO like.
Is there same behaviour for vkQueuePresentKHR and does it count just like another queued command submission, if we are calling both methods on the same queue?
Can I expect that the same-queue-wise if I submit commands through vkQueueSubmit and later in the same thread I call vkQueuePresentKHR the submitted commands are exectude BEFORE the presentation is done?
I assume yes, as they both have "queue" in their name and if they operate on the same queue (this is probably important as if we would submit and present on different quues then there is clearly a problem...), but maybe the asumption is wrong and this must be taken care off by semaphores?
Actualy is there a reason why vkQueuePresentKHR is not just implemented as a command buffer call that needs to be enqueued and submitted by vkQueueSubmit? I assume that answer is yes, but I do not get why...
Can I expect that the same-queue-wise if I submit commands through
vkQueueSubmitand later in the same thread I callvkQueuePresentKHRthe submitted commands are executed BEFORE the presentation is done?
In general, no. The spec wording on ordering is very subtle. Things "start" in order within a queue, but due to the desire for pipelining through the graphics stages they can actually run out of order and complete out of order. If you need ordering within a single queue you need to enforce it with barriers or semaphores.
Across queues, definitely no - you need semaphores to enforce any kind of ordering.
I assume yes, as they both have "queue" in their name and if they operate on the same queue (this is probably important as if we would submit and present on different quues then there is clearly a problem...), but maybe the asumption is wrong and this must be taken care off by semaphores?
In most implementations the display present queue is a dedicated queue, separate from the graphics queue(s).
Actually is there a reason why vkQueuePresentKHR is not just implemented as a command buffer call that needs to be enqueued and submitted by vkQueueSubmit? I assume that answer is yes, but I do not get why...
Because the display hardware is often different to the graphics hardware, and the present behavior also depends on the window system in use. In mobile, the display processor may not even be from the same vendor as the graphics hardware.