Я слышал, что многие люди, работающие над виртуальной реальностью, рассказывают о гонках по сканлайну и о том, что это должно помочь улучшить задержку при движении к фотону. Однако мне не ясно, как это можно сделать с помощью OpenGL. Может кто-нибудь объяснить, как работает Scanline Racing, и как это можно реализовать на современных графических процессорах.
Ответы:
Когда ваш графический процессор отображает новый кадр на экране, он передает изображение через кабель HDMI (или любой другой вид) в процессе, называемом «сканирование». Пиксели отправляются в линейном порядке, обычно слева направо и сверху вниз. Процесс рассчитан так, что для этого требуется большая часть интервала обновления. Например, при 60 Гц один кадр составляет ~ 17 мс. Каждое сканирование займет, вероятно, около 15-16 мс с интервалом 1-2 мс между точками (точные значения варьируются в зависимости от режима отображения и видео).
Традиционно рендеринг выполняется с двойной буферизацией, что означает, что в памяти GPU хранятся два буфера: один, который в настоящее время сканируется («передний буфер»), и тот, который визуализируется («обратный буфер»). Каждый кадр, два поменялись местами. Графический процессор никогда не рендерится в тот же буфер, который сканируется, что предотвращает появление артефактов из-за потенциальной возможности увидеть части неполного кадра. Однако побочным эффектом этого является увеличение задержки, поскольку каждый кадр может сидеть в буфере в течение нескольких мс, прежде чем он начнет сканироваться.
VR очень чувствителен к задержке, поэтому это нежелательно. Альтернативный подход заключается в рендеринге непосредственно в передний буфер, но очень тщательно продумывайте время, чтобы каждая строка изображения была отрисована незадолго до того, как отсканированное изображение попадет туда. Это называется «гонка по скенлайну» или «гонка по лучу» («луч», напоминающий о CRT-днях прошлого). Это более или менее требует, чтобы вы отображали изображение в порядке строки сканирования, то есть в том же порядке, в котором пиксели сканируются. Его не нужно буквально отображать по одной строке за раз - его можно отображать тонкими полосками высотой в несколько пикселей, но это нужно делать по порядку, поскольку вы не можете вернуться назад и редактировать уже существующие пиксели. был отсканирован.
У этого подхода много недостатков; он имеет очень строгие требования к производительности, должен быть очень тщательно рассчитан по отношению к vsync, и это значительно усложняет процесс рендеринга. Но в принципе это может сократить ваши задержки на миллисекунды, и именно поэтому в этом заинтересованы люди VR.
Самое замечательное в том, что мы наконец можем предсказать точную растровую точность строки сканирования без доступа к запросу для каждой строки сканирования:
https://www.youtube.com/watch?v=OZ7Loh830Ec
Я придумал точные формулы с точностью до микросекунды как смещение VSYNC, чтобы предсказать положение линии разрыва. Линии разрыва во время VSYNC OFF всегда растровы, поэтому вы можете избежать их видимости во время «симулированного рендеринга переднего буфера» на уровне полосы с помощью повторной замены буфера VSYNC OFF.
Обратите внимание на ветку форума - там постоянно добавляется открытый исходный код - https://forums.blurbusters.com/viewtopic.php?f=10&p=32002
Если это интересно, у Dreamcast был режим рендеринга «скачок луча», при котором он мог выделять относительно небольшую долю памяти для кадровых буферов (например, 64 строки сканирования), и он рендерил строки по 32, по очереди синхронизированные с обновление дисплея. Это, однако, было использовано только для экономии памяти. Я сомневаюсь, что кто-то генерировал «модифицированную» геометрию для последних частей дисплея.