J'ai entendu beaucoup de gens qui travaillent sur la réalité virtuelle parler de course de scanline et que cela est censé aider à améliorer la latence pour le mouvement vers photon. Cependant, il n'est pas clair pour moi comment cela peut être fait avec OpenGL. Quelqu'un pourrait-il expliquer comment fonctionne Scanline Racing et comment il peut être mis en œuvre sur des GPU modernes?
Réponses:
Lorsque votre GPU affiche une nouvelle image à l'écran, il transfère l'image via le câble HDMI (ou autre) dans un processus appelé "scanout". Les pixels sont envoyés dans un ordre linéaire, généralement de gauche à droite et de haut en bas. Le processus est chronométré de sorte qu'il prenne la plupart de la durée d'un intervalle de rafraîchissement pour ce faire. Par exemple, à 60 Hz, une trame est d'environ 17 ms. Chaque balayage prendra probablement environ 15-16 ms, avec 1-2 ms de vblank entre les deux (les valeurs exactes varient en fonction de l'affichage et du mode vidéo).
Traditionnellement, le rendu est à double tampon, ce qui signifie qu'il y a deux tampons stockés dans la mémoire du GPU: un qui est actuellement analysé ("tampon avant"), et un qui est rendu à ("tampon arrière"). Chaque trame, les deux sont échangés. Le GPU ne restitue jamais dans le même tampon qui est analysé, ce qui empêche les artefacts dus à la possibilité de voir des parties d'une trame incomplète. Cependant, un effet secondaire de cela est une latence accrue, car chaque trame peut rester dans le tampon pendant plusieurs ms avant de commencer à être balayée.
La VR est très sensible à la latence, ce n'est donc pas souhaitable. Une autre approche consiste à effectuer le rendu directement dans le tampon avant, mais temporisez les choses très soigneusement afin que vous ayez rendu chaque ligne de l'image peu de temps avant que le scanout n'y arrive. C'est ce qu'on appelle «course de scanline» ou «course de faisceau» (le «faisceau» qui remonte aux jours CRT d'antan). Cela nécessite plus ou moins que vous rendiez l'image dans l'ordre de la ligne de numérisation, c'est-à-dire le même ordre dans lequel les pixels sont numérisés. Il ne doit pas être rendu littéralement une ligne à la fois - il peut être rendu en fines bandes de quelques pixels de haut, mais cela doit être fait dans l'ordre, car vous ne pouvez pas revenir en arrière et modifier les pixels qui ont déjà été scanné.
Cette approche présente de nombreux inconvénients; il a des exigences de performances très strictes, doit être synchronisé très soigneusement avec vsync, et il complique grandement le processus de rendu. Mais en principe, cela peut réduire de quelques millisecondes votre latence, ce qui explique pourquoi les VR sont intéressés.
La grande chose est que nous pouvons enfin prédire la précision exacte du raster de la ligne de balayage sans avoir accès à une requête par ligne de balayage:
https://www.youtube.com/watch?v=OZ7Loh830Ec
J'ai trouvé les formules exactes à la microseconde près comme un décalage VSYNC, pour prédire la position d'une ligne de déchirure. Les lignes de déchirure pendant VSYNC OFF sont toujours raster-exactes, vous pouvez donc les éloigner de la visibilité pendant le "rendu de tampon frontal simulé" au niveau de la bande via l'échange de tampon VSYNC OFF répété.
Faites attention au fil de discussion - il y a du code open source qui est continuellement ajouté - https://forums.blurbusters.com/viewtopic.php?f=10&p=32002
Si cela vous intéresse, le Dreamcast avait un mode de rendu "accélérant le faisceau", grâce auquel il était capable de consacrer une fraction relativement petite de la mémoire aux pixels du tampon d'image (par exemple 64 lignes de balayage) et il rendrait des rangées de 32 à leur tour, synchronisées avec la mise à jour de l'affichage. Cependant, cela n'a été utilisé que pour économiser de la mémoire. Je doute que quelqu'un génère une géométrie "modifiée" pour les dernières parties de l'écran.