vkQueuePresentKHR should've signal a fence.

[ghost]

I'm currently debugging an issue with Nvidia driver on Linux where CPU frame submission is way ahead of GPU vsynced timeline because neither vkQueuePresentKHR nor vkAcquireNextImageKHR block the main thread (unlike on Windows, on Windows vkQueuePresentKHR blocks & everything works fine).

This basically means if vkQueuePresentKHR or vkAcquireNextImageKHR won't block for some reason, there is no way to know if a particular presentation submit call has finished on a GPU.

This wouldn't be an issue if vkQueuePresentKHR simply could signal a fence, this way I could wait on it explicitly instead of relying on an implicit driver promise of wait.

[krOoze]

presentation submit call has finished on a GPU

Define "finished". When you present something, it is presented indefinitely. That is, until you present something else.

If you mean VSync, then possibly duplicate of #370.

[ghost]

@krOoze yea, I mean vsync. Indeed it looks like #370 is about the same issue.

and thus the only factor metering rendering speed here is the implicit assumption that vkAcquireNextImageKHR will block if the available swapchain images are all stuck in the presentation queue

[ghost]

It seems like changing this at the source requires either vkQueuePresentKHR to signal a fence once the frame either leaves the frame queue (and becomes the active front-buffer), or once it's done being (and the contents have effectively been fully sent to the GPU).

Yeah, ok, definitely a duplicate of #370. Closing.