Я хочу поспать около 10 миллисекунд, затем прочитать некоторые входные данные в реальном времени и выполнить рендеринг как можно позже, при этом все же удается обновить кадр до крайнего срока (для рендеринга с частотой 60 FPS с минимальной задержкой).
Это очень ненадежный подход. Я предлагаю вам поместить все операции рендеринга в их собственный поток, который будет блокировать подкачку буфера до тех пор, пока она не произойдет. Выполните всю обработку ввода в отдельном потоке, где все входные данные накапливаются. Перед выполнением подкачки вы должны поднять мьютекс или семафор в потоке обработки, который делает это во время замены буфера.
Имейте в виду, что вы не должны откладывать рендеринг очень близко к V-Sync, потому что это может привести к его пропуску. Вместо этого вы должны принять около 75% в начале вертикального интервала восстановления времени, которое у вас есть на рендеринг ваших вещей, а остальные 25% должны быть сохранены в качестве запасного запаса. Также, если вы работаете с композитором, для этого нужно немного времени на GPU.
Нет никакой разницы в визуальном результате, если вы рендерите рано или поздно. Если вы беспокоитесь о сроках симуляции: просто предположите, что вы на самом деле сделаете крайний срок и визуализируйте симуляцию для состояния, которое будет в момент V-Sync. Используйте фильтр Калмана на любом вводе данных для симуляции, чтобы рендеринг основывался на предсказаниях и «просто» настраивался на новый ввод.
Я могу использовать glFinish после замены буферов, но, к сожалению, в некоторых системах (по крайней мере, в Linux без композита), это похоже на ожидание не только до следующей замены буфера, но и до отправки изображения через порт HDMI (общее ожидание) в диапазоне 25 мс и приложение работает на скорости 30 FPS).
Это происходит, если ваше время пропускает V-Sync: SwapBuffers будет ожидать полный период вертикального отката. IMHO SwapBuffers должен быть добавлен некоторый параметр тайм-аута, но пока это не так.