Ich habe viele Leute, die an VR arbeiten, über Scanline-Rennen sprechen hören und dass dies dazu beitragen soll, die Latenz für Motion-to-Photon zu verbessern. Allerdings ist mir nicht klar, wie das mit OpenGL gemacht werden kann. Könnte jemand erklären, wie Scanline Racing funktioniert und wie es auf modernen GPUs implementiert werden kann.
Antworten:
Wenn Ihre GPU einen neuen Frame auf dem Bildschirm anzeigt, überträgt sie das Bild über das HDMI-Kabel (oder eine andere Art von Kabel). Dies wird als "Scanout" bezeichnet. Die Pixel werden in linearer Reihenfolge gesendet, normalerweise von links nach rechts und von oben nach unten. Der Prozess ist zeitlich so abgestimmt, dass er die meiste Zeit eines Aktualisierungsintervalls in Anspruch nimmt. Beispielsweise beträgt ein Frame bei 60 Hz ~ 17 ms. Jeder Scan-Vorgang wird voraussichtlich etwa 15 bis 16 ms dauern, wobei zwischen 1 und 2 ms ein Leerzeichen liegt (die genauen Werte variieren je nach Anzeige und Videomodus).
Traditionell wird das Rendern doppelt gepuffert, was bedeutet, dass zwei Puffer im GPU-Speicher gespeichert sind: einer, der gerade gescannt wird ("Front Buffer"), und einer, der auf "Back Buffer" gerendert wird. Bei jedem Frame werden die beiden getauscht. Die GPU rendert niemals in den gleichen Puffer, der gescannt wird, wodurch Artefakte vermieden werden, die möglicherweise auf Teile eines unvollständigen Frames zurückzuführen sind. Ein Nebeneffekt davon ist jedoch die erhöhte Latenz, da jeder Frame einige ms im Puffer herumliegen kann, bevor er mit dem Auslesen beginnt.
VR ist sehr latenzempfindlich, daher ist dies nicht wünschenswert. Ein alternativer Ansatz besteht darin, direkt in den Front-Buffer zu rendern, die Zeit jedoch sehr sorgfältig abzulaufen, sodass Sie jede Zeile des Bildes kurz vor dem Scan-Out gerendert haben. Das nennt man "scanline racing" oder "racing the beam" (der "Strahl", der auf die CRT-Tage von damals zurückgeht). Dies setzt mehr oder weniger voraus, dass Sie das Bild in Scanline-Reihenfolge rendern, dh in derselben Reihenfolge, in der die Pixel gescannt werden. Es muss nicht buchstäblich zeilenweise gerendert werden - es kann in dünnen Streifen mit einer Höhe von einigen Pixeln gerendert werden, dies muss jedoch in der richtigen Reihenfolge erfolgen, da Sie bereits vorhandene Pixel nicht mehr bearbeiten können gescannt worden.
Dieser Ansatz hat viele Nachteile. Es hat sehr strenge Leistungsanforderungen, muss sehr sorgfältig gegen vsync abgestimmt werden und verkompliziert den Rendervorgang erheblich. Aber im Prinzip kann es Millisekunden Ihrer Latenz verkürzen, weshalb VR-Leute daran interessiert sind.
Das Tolle ist, dass wir endlich die genaue Rastergenauigkeit der Scanlinie vorhersagen können, ohne Zugriff auf eine Abfrage pro Scanlinie zu haben:
https://www.youtube.com/watch?v=OZ7Loh830Ec
Ich habe mir die genauen mikrosekundengenauen Formeln als VSYNC-Offset ausgedacht, um die Position einer Träne vorherzusagen. Tränenlinien während VSYNC OFF sind immer rastergenau, sodass Sie sie während des "simulierten Front-Buffer-Renderings" auf Strip-Ebene durch wiederholtes VSYNC OFF-Buffer-Swapping aus der Sichtweite bringen können.
Achten Sie auf den Forenthread - es wird ständig Open Source-Code hinzugefügt - https://forums.blurbusters.com/viewtopic.php?f=10&p=32002
Wenn es von Interesse ist, verfügt der Dreamcast über einen Rendering-Modus "Racing the Beam", mit dem er einen relativ kleinen Teil des Speichers für Framebuffer-Pixel (z. B. 64 Scan-Zeilen) bereitstellen und Reihen mit jeweils 32 synchronisieren kann das Display Update. Dies wurde jedoch nur zum Speichern von Speicher verwendet. Ich bezweifle, dass irgendjemand eine "modifizierte" Geometrie für letztere Teile der Anzeige erzeugt hat.