Bartosz Bazyluk OpenGL Deferred shading. Pętla główna i jej implementacje. Debugowanie i analiza wydajności.
Algorytmy grafiki komputerowej czasu rzeczywistego, Informatyka S2 FORWARD SHADING
W klasycznym podejściu Geometria Shading (ang. forward shading) oświetlenie jest obliczane dla każdego fragmentu powstałego przy Geometria Shading renderowaniu kolejnych elementów sceny. Geometria Shading Framebuffer W ten sposób dla każdego piksela bufora klatki wielokrotnie wykonuje się czasochłonne Geometria Shading obliczenia zupełnie na darmo.
Oczywiście stosowane są różne optymalizacje zmniejszające ten Geometria Shading problem, jednak nie można go całkowicie wyeliminować.
Wydajność potoku jest więc ściśle zależna od złożoności geometrii, a także od liczby źródeł światła.
28 listopada 2016 r. Bartosz Bazyluk 2 DEFERRED SHADING
Podejście z odroczonym cieniowaniem Geometria (ang. deferred shading) polega na przebudowie potoku tak, by właściwe cieniowanie Geometria odbywało się dopiero po wyrenderowaniu geometrii. Geometria G-Buffer Shading Framebuffer Na pierwszym etapie obliczane są tylko podstawowe wartości, które posłużą później do właściwego Geometria obliczenia oświetlenia.
Najbardziej kosztowne operacje Geometria związane z oświetleniem są zatem zawsze wykonywane tyle razy, ile mamy pikseli w buforze klatki (w uproszczeniu), a więc niezależnie od faktycznej złożoności geometrii.
28 listopada 2016 r. Bartosz Bazyluk 3 DEFERRED SHADING
Technika nie jest nowością. Idea pochodzi już z początku lat ‘90, ale popularność w grach zyskała dopiero w ciągu ostatnich lat.
Saito, Takahashi. „Comprehensible rendering of 3D shapes”
Screen z UE3 prezentuje technikę Deferred Shading ze 123 dynamicznymi światłami (rok 2011)
Źródło obrazu: Epic Games, UDK
28 listopada 2016 r. Bartosz Bazyluk 4 DEFERRED ● Proces dwuetapowy ● Geometry pass SHADING – Wejście: geometria sceny – Wyjście: G-Buffer (Geometry buffer)
● Zbiór wartości które przydadzą się do obliczenia oświetlenia ● Multiple render targets (MRT) Drugi etap nie musi dotyczyć wyłącznie oświetlenia. ● Lighting pass (deferred pass) Można odroczyć też wiele innych – Wejście: G-Buffer operacji aż do momentu gdy będziemy mieli wyrenderowaną – Wyjście: gotowa zawartość klatki całą źródłową geometrię.
Geometry Lighting Frame Geometria G-Buffer pass pass buffer
28 listopada 2016 r. Bartosz Bazyluk 5 DEFERRED ● G-Buffer ● Realizuje się go jako FBO SHADING posiadający kilka color attachments
● Zwykle dużo obszerniejszy niż zwyczajny framebuffer przechowujący gotową klatkę – Konieczne rozsądne zarządzanie pamięcią
Zawartość G-Buffera może ● Przykładowe składowe: być dowolna. – Położenie w przestrzeni świata
Należy zastanowić się które ● Zakładając że źródła światła też są w niej określone wartości można efektywnie – Wektor normalny wyliczyć już w pierwszym przebiegu renderowania. – Albedo (kolor pochodzący z materiału, tekstury...) – Mnożnik specular, shininess – Komponent emissive – Wektor ruchu (np. dla motion blur) – Odległość (np. dla depth of field) – Współrzędne tekstury – Współczynnik przysłonięcia słońca – ...
28 listopada 2016 r. Bartosz Bazyluk 6 DEFERRED ● G-Buffer ● Warto zastanowić się nad efektywnym zaplanowaniem SHADING przydziału pamięci – Różne formaty tekstur – Łączenie ze sobą składowych w obrębie jednej tekstury Color attachments podłączone do jednego FBO wcale nie muszą mieć wszystkie ● Przykład – Killzone 2: tego samego formatu.
Wymiary tekstur również nie muszą być identyczne, ale wówczas renderowanie będzie się odbywało tylko do wymiarów najmniejszej z nich – zwykle nie jest to więc oczekiwany rezultat.
Źródło obrazu: Sony, Guerilla Games
28 listopada 2016 r. Bartosz Bazyluk 7 DEFERRED Scena Geometry pass SHADING FBO
Pierwszym krokiem jest Depth/stencil attachment wyrenderowanie geometrii sceny z użyciem shadera, który Pozycja zapisze do odpowiednich Wektory normalne attachments takie wartości, G-Buffer które później będą niezbędne Albedo do obliczenia oświetlenia. ... Na przykład jest to pozycja w przestrzeni świata, wektor normalny, albedo (kolor).
Bufor głębokości również może być częścią G-Buffera jeśli będziemy potrzebować jego zawartości w kolejnym kroku.
28 listopada 2016 r. Bartosz Bazyluk 8 DEFERRED Scena Geometry pass SHADING FBO
Poszczególne attachments Depth/stencil attachment tworzące G-Buffer są następnie podłączane jako tekstury do Pozycja kolejnego etapu. Wektory normalne G-Buffer Ten etap odbywa się Albedo w przestrzeni ekranu, technicznie jest więc etapem ... post processingu.
Shader na tym etapie oblicza oświetlenie dla każdego fragmentu, a więc dla każdego piksela ekranu, na podstawie Full-screen quad Lighting pass danych odczytanych z G-Buffera.
Default framebuffer
28 listopada 2016 r. Bartosz Bazyluk 9 DEFERRED Scena Geometry pass SHADING FBO
Dodatkowo można dokonać Depth/stencil attachment blittingu bufora głębokości otrzymanego w pierwszym Pozycja przebiegu. Wektory normalne G-Buffer W ten sposób możliwe będzie Albedo ) g użycie rezultatu lighting pass n i t t i z testem głębokości tak, jakby ... l b powstał podczas zwyczajnego r e f f
forward shadingu. u b e m a r f (
Full-screen quad Lighting pass
Default framebuffer
28 listopada 2016 r. Bartosz Bazyluk 10 DEFERRED Scena Geometry pass SHADING FBO
Bufor klatki można wtedy Depth/stencil attachment używać do kolejnych etapów )
G-Buffer g n
renderowania, także takich i t t i
z użyciem forward shadingu. l b
r e f f
W ten sposób można dołożyć Full-screen quad Lighting pass u b
kolejne obiekty, e m a np. z przezroczystością lub takie r f które nie biorą udziału ( w oświetleniu, a test głębokości Default framebuffer zadziała poprawnie.
Dodatkowa geometria Additional forward pass
Default framebuffer
28 listopada 2016 r. Bartosz Bazyluk 11 DEFERRED SHADING
Pozycja XYZ we współrzędnych świata dla każdego z fragmentów, zapisana jako RGB.
Pozycja będzie potrzebna do określenia kierunku padania światła ze źródeł, a także do określenia odległości fragmentu od świateł. Można ją pominąć, wykorzystując głębokość i położenie w screen space.
Koniecznie należy tutaj użyć tekstury zmiennoprzecinkowej. Współrzędne rozciągają się przecież poza zakres 0.0-1.0!
Można rozważyć przeskalowanie i przesunięcie wartości dla osiągnięcia najlepszej precyzji.
28 listopada 2016 r. Bartosz Bazyluk 12 DEFERRED SHADING
XYZ wektorów normalnych we współrzędnych świata.
Analogicznie do pozycji, wartości zapisuje się odpowiednio jako składowe R, G i B.
Warto zwrócić uwagę że wektory normalne zawsze przyjmują wartości z zakresu -1.0-1.0. Można zatem przeskalować je by zmieściły się w zakresie 0.0-1.0 i użyć tekstury RGB8, jednak wówczas precyzja może być zbyt mała.
Wektory normalne mogą pochodzić z normal mappingu.
28 listopada 2016 r. Bartosz Bazyluk 13 DEFERRED SHADING
Albedo czyli kolor który później zostanie użyty jako kolor materiału dla komponentu diffuse.
W naszym przypadku jest to kolor odczytany z tekstur na podstawie wysokości terenu i jego nachylenia.
Można rozważyć odroczenie odczytów z tekstur, do G-Buffera zapisując jedynie współrzędne UV, jednak wówczas nie będzie możliwe wygodne korzystanie z mimappingu oraz filtracji anizotropowej.
28 listopada 2016 r. Bartosz Bazyluk 14 DEFERRED SHADING
Obliczenie oświetlenia korzystając ze składowych G-Buffera oraz listy źródeł światła.
Dodatkowo na tym etapie została obliczona mgła na podstawie odległości fragmentów od kamery.
Rezultat zawiera liniowe wartości wykraczające poza zakres 0.0-1.0, przedstawiony jest tutaj bez tone mappingu.
28 listopada 2016 r. Bartosz Bazyluk 15 DEFERRED SHADING
Rezultat po dodaniu skydome’a i po zastosowaniu mapowania tonów.
Skydome został dodany za pomocą forward passa, korzystając z bufora głębokości powstałego w geometry pass.
28 listopada 2016 r. Bartosz Bazyluk 16 DEFERRED ● Istotną kwestią jest dobór formatów tekstur ● Dane o pozycji wymagają dużej precyzji i formatu SHADING zmiennoprzecinkowego
● RGB16F zwykle nie jest wystarczający!
Problem wynika ze zbyt małej precyzji formatu tekstury, gdzie każdy z komponentów XYZ pozycji przechowywany jest za pomocą liczby 16-bitowej.
Kłopot pojawia się gdy takie wartości o stosunkowo małej rozdzielczości biorą udział w rozwiązywaniu modelu oświetlenia.
Wskazane jest używanie 32 bitów na każdy z komponentów.
28 listopada 2016 r. Bartosz Bazyluk 17 DEFERRED ● Deferred shading ma przede wszystkim jeden cel ● Zredukować zależność szybkości renderowania SHADING od liczby źródeł światła i złożoności sceny
● W klasycznym deferred shadingu, gdzie głównym kosztem jest oświetlenie, czas przygotowania klatki zależy głównie od liczby pikseli na ekranie
Należy pamiętać, że w niektórych przypadkach 1: Geometry pass 2: Lighting pass forward shading może ● ● okazać się szybszy! Cała geometria Tylko full-screen quad ● Wiele fragmentów ● Tyle fragmentów ile pikseli Deferred shading ● Zwykle ● Właściwie, jest przeznaczony do sytuacji gdy mamy bardzo złożoną mało kosztowny kosztowne oświetlenie geometrię i dużą liczbę Fragment Shader we Fragment Shaderze dynamicznych źródeł światła.
28 listopada 2016 r. Bartosz Bazyluk 18 DEFERRED ● Light culling SHADING ● Źródła światła mają określony zasięg ● Branie pod uwagę każdego źródła światła dla każdego piksela ekranu jest nieefektywne
Niektóre źródła światła celowo dotyczą całego ekranu, np. słońce w środowiskach otwartych.
Wówczas jak najbardziej właściwym jest uwzględnianie tego źródła światła przy cieniowaniu każdego piksela.
28 listopada 2016 r. Bartosz Bazyluk 19 DEFERRED ● Light culling SHADING ● Źródła światła mają określony zasięg ● Branie pod uwagę każdego źródła światła dla każdego piksela ekranu jest nieefektywne
● Light volumes – Ograniczenie zasięgu wpływu poszczególnych źródeł światła Renderowanie brył światła – Oddzielne przebiegi dla źródeł światła powoduje wygenerowanie fragmentów związanych z tą ● Oddzielne żądania renderowania częścią ekranu, na którą światło Forward-rendering z geometrią która przybliża kształt światła ma faktyczny wpływ. ● Inne podejście Full-screen quad oraz stencil buffer dla maskowania – Addytywny blending uzyskanych rezultatów
∑ =
28 listopada 2016 r. Bartosz Bazyluk 20 DEFERRED SHADING
Wpływ świateł jest kolejno dodawany z użyciem addytywnego blendingu.
Dzięki zastosowaniu light volumes, każdorazowo modyfikowana jest wyłącznie część klatki.
Źródło obrazu: Rockstar Games http://www.adriancourreges.com/
28 listopada 2016 r. Bartosz Bazyluk 21 DEFERRED SHADING
Wpływ świateł jest kolejno dodawany z użyciem addytywnego blendingu.
Dzięki zastosowaniu light volumes, każdorazowo modyfikowana jest wyłącznie część klatki.
Źródło obrazu: Rockstar Games http://www.adriancourreges.com/
28 listopada 2016 r. Bartosz Bazyluk 22 DEFERRED SHADING
Wpływ świateł jest kolejno dodawany z użyciem addytywnego blendingu.
Dzięki zastosowaniu light volumes, każdorazowo modyfikowana jest wyłącznie część klatki.
Źródło obrazu: Rockstar Games http://www.adriancourreges.com/
28 listopada 2016 r. Bartosz Bazyluk 23 DEFERRED SHADING
Wpływ świateł jest kolejno dodawany z użyciem addytywnego blendingu.
Dzięki zastosowaniu light volumes, każdorazowo modyfikowana jest wyłącznie część klatki.
Źródło obrazu: Rockstar Games http://www.adriancourreges.com/
28 listopada 2016 r. Bartosz Bazyluk 24 DEFERRED ● Light culling SHADING ● Źródła światła mają określony zasięg ● Branie pod uwagę każdego źródła światła dla każdego piksela ekranu jest nieefektywne
● Light volumes – Bryła przypominająca zasięg światła Promień kuli można wyznaczyć z równania tłumienia światła wraz z odległością (attenuation).
1 a (d )= 2 k c +k l d +k q d
Kule jako aproksymacja zasięgu point lights rozsianych na scenie.
Źródło obrazu: http://richdavison.co.uk/
28 listopada 2016 r. Bartosz Bazyluk 25 DEFERRED ● Light culling SHADING ● Źródła światła mają określony zasięg ● Branie pod uwagę każdego źródła światła dla każdego piksela ekranu jest nieefektywne
● Light volumes – Bryła przypominająca zasięg światła Promień kuli można wyznaczyć z równania tłumienia światła wraz z odległością (attenuation).
1 a (d )= 2 k c +k l d +k q d
Kule jako aproksymacja zasięgu point lights rozsianych na scenie.
Źródło obrazu: http://richdavison.co.uk/
28 listopada 2016 r. Bartosz Bazyluk 26 DEFERRED ● Light culling SHADING ● Źródła światła mają określony zasięg ● Branie pod uwagę każdego źródła światła dla każdego piksela ekranu jest nieefektywne
● Light volumes – Axis-Aligned Bounding Box (AABB) Renderowanie kuli jest raczej niepotrzebnym przerostem formy nad treścią, wprowadza zbyt wiele wierzchołków.
Efektywniejszym rozwiązaniem jest posłużenie się przybliżoną bryłą lub kształtem w przestrzeni ekranu.
Należy pamiętać o zasięgu komponentu specular który może być znacznie większy.
28 listopada 2016 r. Bartosz Bazyluk 27 DEFERRED ● Light culling SHADING ● Źródła światła mają określony zasięg ● Branie pod uwagę każdego źródła światła dla każdego piksela ekranu jest nieefektywne
● Light volumes – Axis-Aligned Bounding Box (AABB)
Podstawowy problem: dużo zachodzących na siebie obszarów, a więc niepotrzebnie zwielokrotnione odczyty z G-Buffera - dla każdego żądania renderowania, dla każdego fragmentu osobno.
28 listopada 2016 r. Bartosz Bazyluk 28 DEFERRED ● Light culling SHADING ● Źródła światła mają określony zasięg ● Branie pod uwagę każdego źródła światła dla każdego piksela ekranu jest nieefektywne
● Light volumes – Oriented Bounding Box (OBB)
Aby lepiej oddać kształt np. światła stożkowego (spotlight) o bardzo wąskim kącie świecenia i nie angażować niepotrzebnie dużo zbędnych pikseli, można posłużyć się OBB.
28 listopada 2016 r. Bartosz Bazyluk 29 DEFERRED ● Light culling SHADING ● Źródła światła mają określony zasięg ● Branie pod uwagę każdego źródła światła dla każdego piksela ekranu jest nieefektywne
● Light volumes: grupowanie źródeł światła Duża liczba żądań renderowania – Utworzenie pojedynczego light volume dla kilku znajdujących też jest istotnym problemem się w pobliżu źródeł światła często bywa bardziej efektywne który można próbować (mniej żądań renderowania) zredukować.
2. Render call (2 światła)
1. Render call (3 światła)
28 listopada 2016 r. Bartosz Bazyluk 30 DEFERRED ● Light culling SHADING ● Źródła światła mają określony zasięg ● Branie pod uwagę każdego źródła światła dla każdego piksela ekranu jest nieefektywne
● Tiled shading – Podział przestrzeni ekranu na kafelki (ang. tiles) – Osobna lista świateł dla każdego kafelka – Redukuje problem wielokrotnego dostępu do G-Buffera przy renderowaniu light volumes
Wizualizacja liczby źródeł światła dla każdego z kafelków. Im jaśniejszy kolor kafelka, tym więcej źródeł światła jest branych pod uwagę.
Źródło obrazu: Leif Erkenbrach, http://leifnode.com
28 listopada 2016 r. Bartosz Bazyluk 31 DEFERRED ● Technika deferred shading posiada istotne wady ● Kłopoty z antialiasingiem SHADING – Rezultat geometry pass można zapisać w buforze z multisamplingiem, ale wywołanie go przed lighting passem spowoduje uzyskanie niepoprawnych wartości!
● Np. pozycja ulegnie uśrednieniu na granicach obiektów ● Konieczne jest ręczne odczytywanie wielu próbek z bufora podczas wykonywania lighting pass ● Istnieją różne adaptacyjne techniki pozwalające zoptymalizować takie podejście, dokonując odczytywania wielu próbek wyłącznie dla krawędzi obiektów
● Brak obsługi przezroczystości – Zawartość G-Buffera dotyczy tylko geometrii która jest najbliższa kamery
● Przezroczyste obiekty zwykle dodaje się w oddzielnym passie
● Potrzeba dużej ilości pamięci do przechowania G-Buffera
● Jeden shader dla wszystkich renderowanych obiektów
28 listopada 2016 r. Bartosz Bazyluk 32 DEFERRED ● Rozwinięcie idei deferred shading ● Nazywane często Light pre-pass LIGHTING – Odroczone renderowanie pełnoekranowej light mapy, która później jest używana do oświetlenia geometrii ● Trzy przebiegi
● Geometry pass – Wejście: Geometria – Wyjście: G-Buffer
● Lighting pass – Wejście: G-Buffer – Wyjście: Full-screen light map
● Final pass – Wejście: Geometria + Full-screen light map – Wyjście: Gotowa klatka
28 listopada 2016 r. Bartosz Bazyluk 33 DEFERRED LIGHTING
Przykładowa pełnoekranowa mapa światła.
Źródło obrazu: Sony, Guerilla Games
28 listopada 2016 r. Bartosz Bazyluk 34 DEFERRED Scena Geometry pass LIGHTING FBO
G-Buffer
Full-screen quad Lighting pass
Komponenty światła można FBO traktować osobno. Diffuse map
Specular map
28 listopada 2016 r. Bartosz Bazyluk 35 DEFERRED Scena Geometry pass LIGHTING FBO
G-Buffer
Full-screen quad Lighting pass
FBO
Full-screen light map Podczas ostatniego przebiegu jest dostęp do pełnej informacji o geometrii sceny, możliwy jest Scena Final pass więc łatwiejszy antialiasing.
Default framebuffer
28 listopada 2016 r. Bartosz Bazyluk 36 GAME LOOP
Tym co odróżnia sposób działania gry komputerowej od aplikacji użytkowej jest schemat cyklu prowadzenia obliczeń.
O ile najczęściej zadaniem aplikacji użytkowej jest generowanie odpowiedzi na żądania ze strony użytkownika, o tyle gra nawet jeśli te żądania nie nadchodzą, dokonuje ciągłej symulacji świata rozgrywki.
Podstawą architektury aplikacji grafiki czasu rzeczywistego jest więc nieskończona pętla główna.
28 listopada 2016 r. Bartosz Bazyluk 37 GAME LOOP ● Nieskończona pętla ● Warunkiem stopu jest wystąpienie żądania zakończenia działania programu ● Postać podstawowej wersji pętli:
while (użytkownik nie chce wyjść) { sprawdź urządzenia wejścia; wykonaj zadania AI; przemieść przeciwników; sprawdź kolizje; renderuj świat; odtwórz dźwięki; prześlij dane do serwera; ... }
28 listopada 2016 r. Bartosz Bazyluk 38 ● W dalszych rozważaniach przyjmiemy uproszczenie, GAME LOOP że podstawowy game loop ma postać:
while (użytkownik nie chce wyjść) { aktualizuj stan gry; renderuj świat gry; }
● Zatem zdefiniujmy następujące określenia:
● Aktualizacja stanu gry – Wszystkie operacje wpływające na stan świata, wynik rozgrywki, pozycję obiektów, obsługa wejścia i zdarzeń, ...
● Renderowanie świata gry – Wybór obiektów do renderowania, wyznaczenie ich macierzy przekształceń, zlecenie renderowania karcie graficznej, zamiana buforów, ...
28 listopada 2016 r. Bartosz Bazyluk 39 WYŚWIETLANIE ● Współczesne wyświetlacze komputerowe traktują KLATEK obraz jako raster ● Wyświetlacze działają ze stałą częstotliwością odświeżania (dawniej odchylania pionowego)
● Najczęściej spotykaną częstotliwością odświeżania jest obecnie 60Hz
● Dla obrazu stereoskopowego, będzie to dwa razy więcej
Progresywne wyświetlanie klatki:
1/60s
Źródło obrazu: http://www.wikipedia.org
28 listopada 2016 r. Bartosz Bazyluk 40 WYŚWIETLANIE ● Karta graficzna odpowiada za przygotowanie zawartości klatki, przechowywanie jej i wysłanie KLATEK do monitora gdy ten będzie gotowy wyświetlić kolejną klatkę
● Obraz do wyświetlenia przechowywany jest w buforze klatki
● Proces generowania zawartości bufora klatki i proces przesyłania jej do wyświetlacza są niezależne
Program Renderowanie
Bufor klatki
Wyświetlanie
KARTA GRAFICZNA
28 listopada 2016 r. Bartosz Bazyluk 41 WYŚWIETLANIE ● Aby uniknąć migotania obrazu podczas jego przerysowywania gdy występuje konieczność jego KLATEK akutalizacji, stosuje się technikę podwójnego buforowania (ang. double buffering) ● Mamy wówczas dwa bufory klatki: Komponowanie zawartości bufora klatki nie jest ● Bufor "przedni" (ang. front buffer) natychmiastowe. – Jest wyświetlany W grafice czasu rzeczywistego ● Bufor "tylny" (ang. back buffer) elementy sceny renderowane są – Jest aktualizowany jeden po drugim. Zatem dopóki nie zakończy się renderowanie ● Gdy zakończy się aktualizacja back buffera, wszystkich elementów sceny, bufor klatki może zawierać zamieniane są one miejscami (ang. buffer swap) nieukończony obraz.
Użycie podwójnego buforowania Front rozwiązuje ten problem. Dopóki nowa klatka nie zostanie Front ukończona, wyświetlana będzie poprzednia klatka. Back
28 listopada 2016 r. Bartosz Bazyluk 42 WYŚWIETLANIE ● Aby uniknąć migotania obrazu podczas jego przerysowywania gdy występuje konieczność jego KLATEK akutalizacji, stosuje się technikę podwójnego buforowania (ang. double buffering) ● Mamy wówczas dwa bufory klatki: Komponowanie zawartości bufora klatki nie jest ● Bufor "przedni" (ang. front buffer) natychmiastowe. – Jest wyświetlany W grafice czasu rzeczywistego ● Bufor "tylny" (ang. back buffer) elementy sceny renderowane są – Jest aktualizowany jeden po drugim. Zatem dopóki nie zakończy się renderowanie ● Gdy zakończy się aktualizacja back buffera, wszystkich elementów sceny, bufor klatki może zawierać zamieniane są one miejscami (ang. buffer swap) nieukończony obraz.
Użycie podwójnego buforowania Back rozwiązuje ten problem. Dopóki nowa klatka nie zostanie Front ukończona, wyświetlana będzie poprzednia klatka. Front
28 listopada 2016 r. Bartosz Bazyluk 43 WYŚWIETLANIE ● Dla zachowania wrażenia płynności wyświetlanego ruchomego obrazu, należy upewnić się że kolejne KLATEK klatki animacji będą docierać do monitora, gdy ten będzie gotowy je wyświetlić ● W tym celu stosuje się tzw. synchronizację pionową (ang. vertical synchronisation / VSync)
● Sterownik karty graficznej lub program czeka z zamianą buforów, aż monitor będzie gotowy wyświetlić kolejną klatkę
● W innym wypadku pomimo sprzętowej możliwości wygenerowania nawet większej liczby klatek na sekundę niż wyświetla monitor, obraz nie będzie płynny
● Artefakt nazywany tearing, wyświetlany obraz składający się z więcej niż jednej klatki
28 listopada 2016 r. Bartosz Bazyluk 44 WYŚWIETLANIE czas renderowania jednej klatki
KLATEK cykl odświeżenia obrazu na wyświetlaczu
Dla wyświetlaczy oferujących wyższą częstotliwość odświeżania VSync Off max FPS ekranu niż 60Hz, czas cyklu będzie swap interval = 0 krótszy niż 1/60s.
VSync On (sleep) (sleep) 60 FPS swap interval = 1
Procesor graficzny czekając VSync On na gotowość wyświetlacza (sleep) (sleep) (sleep) 30 FPS swap interval = 2 nie musi wykonywać operacji, podczas gdy bez użycia synchronizacji od razu zaczynałby 1/60s 1/60s renderować kolejną klatkę.
Użycie synchronizacji pionowej czas może więc też prowadzić do zmniejszenia zużycia energii. ● Możliwość ustawienia interwału w GLFW:
glfwSwapInterval(interval);
28 listopada 2016 r. Bartosz Bazyluk 45 WYŚWIETLANIE Synchronizacja pionowa Synchronizacja pionowa wyłączona włączona KLATEK
Artefakt tego rodzaju nazywa się często ang. słowem tearing.
28 listopada 2016 r. Bartosz Bazyluk 46 WYŚWIETLANIE ● Technologia NVIDIA G-Sync ● Synchronizacja wyświetlacza z kartą graficzną KLATEK – czyli podejście odwrotne
● Wyświetlacz ma adaptacyjną częstotliwość odświeżania, dostosowującą się do aktualnej liczby klatek na sekundę – Zakres 30-144 Hz, zależnie od sprzętu
● Podejście wbrew pozorom nie jest nowe, podobne rozwiązanie Adaptive Sync jest częścią standardu DisplayPort 1.2a – zaimplementowane choćby przez AMD w ich FreeSync; różnice: – G-Sync duplikuje klatki gdy ich częstotliwość poniżej minimum – G-Sync zapobiega nadpisywaniu klatek
Źródło obrazu: NVIDIA
28 listopada 2016 r. Bartosz Bazyluk 47 POMIAR ● Cząstkowy pomiar czasu (np. rysowania jednego obiektu) jest niemiarodajny SZYBKOŚCI DZIAŁANIA ● kolejkowanie, buforowanie, etc. w karcie graficznej
double t0 = glfwGetTime(); glDrawArrays(...); double t = glfwGetTime() - t0; Wpływ na szybkość renderowania – Pomiar czasu wykonania linijki odpowiadającej za żądanie ma bardzo wiele czynników. renderowania najczęściej da czas zbliżony do zera
Brak liniowej zależności ● Wartościowy jest pomiar czasu pomiędzy kolejnymi czasu renderowania momentami zamiany buforów (buffer swap) od złożoności sceny: Renderowanie 10.000 wielokątów ● Sumaryczny czas tworzenia całej klatki nie jest dwa razy szybsze aktualizuj stan gry; niż renderowanie 20.000. renderuj świat gry;
t0 = glfwGetTime(); double t = t0 – prevT0; prevT0 = t0;
Więcej na ten temat: – Niewiele mówi o faktycznym czasie renderowania sceny http://www.opengl.org/wiki/Performance http://www.mvps.org/directx/articles/fps_versus_frame_time.htm jeśli jest włączona synchronizacja pionowa
28 listopada 2016 r. Bartosz Bazyluk 48 POMIAR ● Liczba klatek na sekundę (ang. frames per second, FPS) SZYBKOŚCI DZIAŁANIA ● Miara nieliniowa
– Spadek liczby FPS z 900 do 450 jest tym samym, co z 60 do 56.25! ● Czas klatki (ang. frame time) Należy odróżnić czas ● renderowania klatki od czasu Miara liniowa trwania aktualizacji stanu. ● Pozostałe składowe czasu przygotowania klatki Użytkownik widzi tylko czas ● Czas aktualizacji stanu renderowania, ale podczas ● Opóźnienie wynikające z działania urządzeń wejścia/wyjścia optymalizacji należy mieć na uwadze faktyczne przyczyny trwania cyklu przygotowania kolejnej klatki animacji.
Więcej na ten temat: http://www.opengl.org/wiki/Performance http://www.mvps.org/directx/articles/fps_versus_frame_time.htm
28 listopada 2016 r. Bartosz Bazyluk 49 POMIAR ● Użycie dedykowanych narzędzi SZYBKOŚCI DZIAŁANIA ● Debugowanie – Analiza stanu serwera OpenGL – Analiza zawartości pamięci karty graficznej
● Profiling Z racji buforowania instrukcji, – Znajdowanie wąskich gardeł zwykle okazuje się że najwięcej – Czas wykonania funkcji z API OpenGL nie mówi o faktycznym czasu zajmuje wykonywanie koszcie danych operacji! buffer swap. ● Dostępne narzędzia: Nie oznacza to, że sama zamiana – NVIDIA Nsight buforów jest wąskim gardłem! W tym czasie wykonywane ● Tylko GPU NVIDIA są wszystkie dotychczas – AMD CodeXL zbuforowane żądania ● Dowolne GPU (jeśli chodzi o debugowanie OpenGL) renderowania. ● Dawniej gDEBugger – RenderDoc, GLIntercept, glslDevil, Apitrace, ...
28 listopada 2016 r. Bartosz Bazyluk 50 GAME LOOP IMPLEMENTACJE
Za przykład do analizy posłuży nam prosty, obracający się sześcian.
Kod przykładu jest uproszczony i celowo korzysta z archaicznego immediate mode.
Kody źródłowe dostępne na: http://bazyluk.net/dydaktyka
28 listopada 2016 r. Bartosz Bazyluk 51 GAME LOOP ● Najprostsza forma: IMPLEMENTACJE while (użytkownik nie chce wyjść) { aktualizuj stan gry; Podstawowy game loop renderuj świat gry; }
Aktualizacja występuje ze stałym krokiem.
Absolutnie nie jest to podejście zalecane! ● Zalety:
● Prostota (?)
● Problemy:
● Szybkość rozgrywki zależna od wydajności sprzętu
● Szybkość rozgrywki może się zmieniać w trakcie gry
28 listopada 2016 r. Bartosz Bazyluk 52 ● Określamy, co ile czasu ma wykonać się aktualizacja GAME LOOP stanu gry. IMPLEMENTACJE ● Każda aktualizacja stanu zawsze oznacza następujące Stała szybkość gry po nim renderowanie obrazu.
Podejście może być korzystne w przypadku gier na urządzenia mobilne. Może bowiem redukować ● Zalety: zużycie energii. ● Stałe tempo gry (o ile wystarczający sprzęt)
● Oszczędność baterii
● Problemy:
● Sprzęt nie daje rady osiągnąć tyle FPS => gra zwalnia.
● Wydajny sprzęt => i tak mamy tyle FPS, co update'ów.
28 listopada 2016 r. Bartosz Bazyluk 53 ● Pozwalamy na renderowanie tak szybko, jak to jest GAME LOOP możliwe. IMPLEMENTACJE ● Każdemu renderowaniu towarzyszy aktualizacja Szybkość gry uzależniona stanu ze zmiennym krokiem. od FPS
Podejście na pierwszy rzut oka bardzo dobre, ale ma istotne słabe strony. ● Zalety:
● Maksymalna liczba FPS
● Problemy:
● Nieprzewidywalność rozgrywki
● Konieczność aktualizacji zależnej od zmiennego czynnika
28 listopada 2016 r. Bartosz Bazyluk 54 GAME LOOP ● Rozwinięcie koncepcji stałego kroku aktualizacji ● Jeśli mamy jeszcze czas do zaplanowanej, następnej IMPLEMENTACJE aktualizacji, to renderujemy dodatkową klatkę.
Stała szybkość gry ● Jeśli mamy opóźnienie, to wykonujemy dodatkową i maksimum FPS aktualizację ze stałym krokiem żeby nadrobić stratę.
Podejście w podstawowej postaci prowadzi do marnowania mocy ● obliczeniowej. Zalety: ● Rozwiązuje problem wpływu długiego czasu renderowania na częstotliwość aktualizacji.
● Eliminuje zbędne oczekiwanie (czasem to minus).
● Problemy:
● Jeśli mamy odpowiednio wydajny sprzęt, renderujemy wiele takich samych klatek.
28 listopada 2016 r. Bartosz Bazyluk 55 ● Aby nie renderować identycznych klatek pomiędzy GAME LOOP aktualizacjami, można dokonać interpolacji. IMPLEMENTACJE ● Wprowadza opóźnienie o wielkości jednego cyklu.
Stała szybkość gry ● Innym, pokrewnym podejściem jest predykcja. i maksimum FPS ● Szczególnie dla wartości kontrolowanych przez gracza może + interpolacja wywołać niepożądane efekty.
Podejście zalecane dla jednowątkowej architektury.
● Zalety:
● Stały krok aktualizacji, maksimum FPS.
● Każda klatka jest inna.
● Problemy:
● Nieznaczne opóźnienie.
28 listopada 2016 r. Bartosz Bazyluk 56 ● Rozdzielenie aktualizacji i renderowania GAME LOOP na dwa osobne wątki, które mogą być IMPLEMENTACJE wykonywane równolegle przez np. procesor Zrównoleglony wielordzeniowy. game loop
Konieczne jest korzystanie z interpolacji bądź predykcji.
Schemat w przykładzie jest tutaj uproszczony. Wątków ● może być znacznie więcej. Zalety: ● Współbieżne renderowanie i aktualizacja, niezależne od siebie.
● Stały krok aktualizacji i maksymalna liczba FPS.
● Problemy:
● Konieczność uważnego planowania architektury silnika.
28 listopada 2016 r. Bartosz Bazyluk 57 ● Jeden kontekst OpenGL może w danym momencie GAME LOOP być używany tylko przez jeden wątek. IMPLEMENTACJE ● Komunikacja CPU -> karta graficzna nie może być Wielowątkowość w grach traktowana jako możliwa do zrównoleglenia. – możliwości i problemy ● Można stworzyć kilka kontekstów, które współdzielą dane – nie jest to jednak podejście wydajne ani zalecane.
● Inne możliwości wykorzystania wielowątkowości: Nie warto uciekać ● Odczyt tekstur i zasobów z dysku odbywający się "w tle". od wielowątkowości w nowoczesnych silnikach. – Dysk nie jest urządzeniem pozwalającym na odczyt równoległy (z wyłączeniem macierzy dyskowych)!
Współczesny sprzęt daje ● Wydajna, zrównoleglona aktualizacja stanu: ogromne możliwości. – Obliczenia AI podzielone na kilka wątków. Należy je wykorzystać. – Symulacja fizyki. – Systemy cząsteczkowe.
● Odtwarzanie dźwięku.
28 listopada 2016 r. Bartosz Bazyluk 58 Bartosz Bazyluk OpenGL Deferred shading. Pętla główna i jej implementacje. Debugowanie i analiza wydajności.
Algorytmy grafiki komputerowej czasu rzeczywistego, Informatyka S2