Słyszałem, że wiele osób pracujących nad VR mówi o wyścigach Scanline i że ma to pomóc w poprawie opóźnień w ruchu od fotonu. Jednak nie jest dla mnie jasne, jak można to zrobić za pomocą OpenGL. Czy ktoś mógłby wyjaśnić, jak działa wyścig Scanline i jak można go zaimplementować w nowoczesnych procesorach graficznych.
Odpowiedzi:
Gdy twój GPU wyświetla na ekranie nową ramkę, przesyła obraz kablem HDMI (lub jakikolwiek inny) w procesie zwanym „skanowaniem”. Piksele są wysyłane w kolejności liniowej, zwykle od lewej do prawej i od góry do dołu. Proces jest tak zaplanowany, że zajmuje to większość czasu interwału odświeżania. Na przykład przy 60 Hz jedna ramka wynosi ~ 17 ms. Każde skanowanie zajmie prawdopodobnie około 15-16 ms, z 1-2 ms vblank pomiędzy nimi (dokładne wartości różnią się w zależności od trybu wyświetlania i wideo).
Tradycyjnie renderowanie jest podwójnie buforowane, co oznacza, że w pamięci GPU są przechowywane dwa bufory: jeden, który jest obecnie skanowany („bufor przedni”), i jeden, który jest renderowany („bufor buforowy”). Każda ramka jest zamieniana. GPU nigdy nie renderuje do tego samego bufora, który jest skanowany, co zapobiega artefaktom ze względu na potencjalnie widzenie części niekompletnej ramki. Jednak efektem ubocznym tego jest zwiększone opóźnienie, ponieważ każda ramka może siedzieć w buforze przez kilka ms, zanim zacznie być skanowana.
VR jest bardzo wrażliwe na opóźnienia, więc nie jest to pożądane. Alternatywnym podejściem jest renderowanie bezpośrednio do przedniego bufora, ale należy bardzo dokładnie określić czas, tak aby każda linia obrazu była renderowana na krótko przed dotarciem do skanu. To się nazywa „wyścigi skanowane” lub „wyścigi wiązką” („wiązka” nawiązująca do dawnych czasów CRT). To mniej więcej wymaga renderowania obrazu w kolejności skanowania, tj. W tej samej kolejności, w której skanowane są piksele. Nie musi być dosłownie renderowany pojedynczo - może być renderowany w cienkie paski o wysokości kilku pikseli, ale musi być wykonywany w kolejności, ponieważ nie można cofać się i edytować pikseli, które już miały został zeskanowany.
Podejście to ma wiele wad; ma bardzo rygorystyczne wymagania wydajnościowe, musi być bardzo dokładnie mierzone względem vsync i znacznie komplikuje proces renderowania. Ale w zasadzie może zmniejszyć milisekundy opóźnienia, dlatego ludzie VR są tym zainteresowani.
Wspaniałą rzeczą jest to, że możemy w końcu przewidzieć dokładną dokładność rastra w linii skanowania bez dostępu do zapytania dla poszczególnych linii:
https://www.youtube.com/watch?v=OZ7Loh830Ec
Wymyśliłem dokładne mikrosekundowe formuły jako przesunięcie VSYNC, aby przewidzieć położenie linii łzy. Tereliny podczas VSYNC OFF są zawsze dokładne rastrowo, więc można je wyprowadzić z widoczności podczas „symulowanego renderowania bufora przedniego” na poziomie paska poprzez powtarzanie zamiany bufora VSYNC OFF.
Zwróć uwagę na wątek forum - ciągle jest dodawany kod open source - https://forums.blurbusters.com/viewtopic.php?f=10&p=32002
Jeśli jest to interesujące, Dreamcast miał tryb renderowania „wyścigi wiązką”, w którym był w stanie poświęcić stosunkowo niewielką część pamięci pikselom bufora ramki (np. 64 linie skanowania) i renderowałby rzędy 32 z kolei zsynchronizowane z aktualizacja wyświetlacza. Służyło to jednak tylko do oszczędzania pamięci. Wątpię, czy ktokolwiek generował „zmodyfikowaną” geometrię dla późniejszych części wyświetlacza.