He escuchado a muchas personas que trabajan en VR hablar sobre las carreras de scanline y que se supone que ayuda a mejorar la latencia del movimiento de fotones. Sin embargo, no está claro para mí cómo se puede hacer esto con OpenGL. ¿Podría alguien explicar cómo funciona el scanline racing y cómo se puede implementar en las GPU modernas?
Respuestas:
Cuando su GPU muestra un nuevo marco en la pantalla, transfiere la imagen a través del cable HDMI (o de cualquier tipo) en un proceso llamado "escaneo". Los píxeles se envían en orden lineal, generalmente de izquierda a derecha y de arriba a abajo. El proceso está cronometrado para que tome la mayor parte de la duración de un intervalo de actualización para hacer esto. Por ejemplo, a 60Hz, un cuadro es ~ 17 ms. Cada escaneo tomará probablemente alrededor de 15-16 ms, con 1-2 ms de vblank en el medio (los valores exactos varían según la pantalla y el modo de video).
Tradicionalmente, la representación tiene doble memoria intermedia, lo que significa que hay dos memorias intermedias almacenadas en la memoria de la GPU: una que se está escaneando actualmente ("memoria intermedia frontal") y otra que se está procesando en ("memoria intermedia posterior"). Cada cuadro, los dos se intercambian. La GPU nunca se procesa en el mismo búfer que se está escaneando, lo que evita los artefactos debido a la posibilidad de ver partes de un marco incompleto. Sin embargo, un efecto secundario de esto es el aumento de la latencia, ya que cada cuadro puede permanecer en el búfer durante varios ms antes de comenzar a escanearse.
La realidad virtual es muy sensible a la latencia, por lo que esto no es deseable. Un enfoque alternativo es renderizar directamente en el búfer frontal, pero agotar el tiempo con mucho cuidado para que haya renderizado cada línea de la imagen poco antes de que llegue el escaneo. Eso se llama "scanline racing" o "racing the beam" (el "haz" que se remonta a los días de CRT de antaño). Esto requiere más o menos que renderice la imagen en el orden de la línea de exploración, es decir, el mismo orden en que se escanean los píxeles. Literalmente, no tiene que procesarse una línea a la vez; podría representarse en tiras delgadas de unos pocos píxeles de altura, pero tiene que hacerse en orden, ya que no puede volver atrás y editar píxeles que ya sido escaneado
Hay muchas desventajas en este enfoque; tiene requisitos de rendimiento muy estrictos, debe sincronizarse con mucho cuidado contra vsync, y complica enormemente el proceso de renderizado. Pero, en principio, puede reducir milisegundos su latencia, razón por la cual la gente de VR está interesada en ella.
Lo bueno es que finalmente podemos predecir la precisión exacta de la línea de exploración sin acceso a una consulta por línea de exploración:
https://www.youtube.com/watch?v=OZ7Loh830Ec
He ideado las fórmulas exactas con precisión de microsegundos como un desplazamiento VSYNC, para predecir la posición de una línea de corte. Las líneas de corte durante VSYNC OFF siempre son exactas por trama, por lo que puede desviarlas de la visibilidad durante el "renderizado simulado del búfer frontal" a nivel de banda mediante el intercambio repetido del búfer VSYNC OFF.
Preste atención al hilo del foro: se agrega continuamente código fuente abierto: https://forums.blurbusters.com/viewtopic.php?f=10&p=32002
Si es de interés, el Dreamcast tenía un modo de renderizado "racing the beam", en el que podía dedicar una fracción relativamente pequeña de memoria a los píxeles de framebuffer (por ejemplo, 64 líneas de exploración) y renderizaba filas de 32 a su vez, sincronizadas con La actualización de la pantalla. Sin embargo, esto solo se usó para ahorrar memoria. Dudo que alguien estuviera generando geometría "modificada" para las últimas partes de la pantalla.