Ответ Никола Боласа верный, но поскольку в ответах на него запрашивались подробности о том, где это используется в реальных реализациях, я добавлю еще один ответ здесь.
На Android vkQueuePresentKHR отправляет изображение вКомпозитор (SurfaceFlinger), который его отображает.Композитор повторно отображает это изображение при каждом обновлении дисплея, пока не получит новое изображение для отображения для этого окна.Пока он не получит следующее изображение, он не будет знать, сколько раз ему понадобится снова прочитать буфер в будущем, и не сможет создать семафор, который будет сигнализировать о завершении последнего чтения.(Гипотетически, вы могли бы создать систему, которая могла бы сделать это, но это не то, как механизмы синхронизации ядра Linux Android использует для этой работы.) Поэтому, пока вы не представите образ N + 1, композитор не сможет выпуститьimage N обратно в ваше приложение для его приобретения, поскольку оно не может дать вам семафор, чтобы пойти вместе с ним.
Это немного сложнее, так как, даже если вы представите кадр N + 1,Композитор не знает, сколько времени пройдет до того, как семафор рендеринга подаст сигнал, поэтому он все еще не знает сразу, сколько еще времени потребуется, чтобы иметь возможность прочитать изображение для кадра N.
Это расширяетк цепочкам обмена с более чем двумя буферами.
Я не так знаком с другими системами, но я полагаю, что у других есть подобные ограничения, которые не позволяют им получать изображения произвольно далеко перед их представлением.Определенно возможно создать механизм представления, который позволил бы это, но Vulkan нужно было работать с существующими системами и существующими механизмами представления, поэтому пришлось мириться с ограничениями, которые накладывают эти существующие системы.Участники Khronos не могут менять композитор Windows, а другие, такие как X11, Wayland и Android, трудно / медленно менять, поскольку это может повлиять на все существующие приложения, платформы и т. Д.