Dlaczego potok programowalny (GLSL) jest szybszy niż potok stały?

Więc uczę się GLSL i próbuję dowiedzieć się, dlaczego to ma być szybsze niż potok funkcji stałej.

Powodem, dla którego mam problem, jest to, że z mojego zrozumienia, tworzone przez ciebie shadery zastępują odcinki rurociągu, które były tam wcześniej. Jak więc po prostu udostępnić własną wersję, która przyspiesza?

Jedyne, co myślę, to to, że jeśli wcześniej spróbujesz podać własne równanie oświetlenia, będziesz musiał wykonać obliczenia na CPU, ale teraz możesz wykonać obliczenia na GPU, które będą szybsze.

Czy rozumiem to poprawnie?

Shadery, które utworzysz, nie będą twoją własną wersją potoku o stałej funkcji (FFP), ale niestandardowe operacje na wierzchołkach i pikselach, aby osiągnąć coś fajnego i złożonego.

Wiele rzeczy, które robisz za pomocą programowalnego potoku (PP) będzie działało szybciej niż ich możliwe implementacje FFP, ponieważ PP zmniejsza liczbę przejść lub ilość magii łączącej i mapowania kubatury wymaganą do renderowania tych hipotetycznych rzeczy w FFP.

Wyobraź sobie implementację tak powszechnej rzeczy jak oświetlenie pikselowe w FFP z tylko interpolowanymi danymi wierzchołków i przykładową teksturą w twoich rękach. Nie można tego nawet zrobić „uczciwie”, tylko hacki w szczególnych przypadkach, w zależności od wiernych, wstępnie obliczonych map sześciennych i poważnego mieszania. W przypadku PP staje się kwestią kolorowania iloczynu między kierunkiem światła a wierzchołkiem normalnym.

Podsumowując, PP zmienia się powoli i niemożliwy w szybki i możliwy. Ale jeśli zdecydujesz się napisać moduł cieniujący, aby zaimplementować te same algorytmy używane w FFP, przekonasz się, że FFP będzie nieco szybszy, ponieważ jest bardzo zoptymalizowany sprzętowo.

Pod względem teoretycznym potok programowalny jest wolniejszy niż potok funkcji stałej. Żaden procesor ogólnego przeznaczenia nie może konkurować ze specjalnym procesorem skrzynek. Pierwotny potok o stałej funkcji był niewiele więcej niż wiązką bramek logicznych w linii, która jest tak szybka, jak teoretycznie jest to możliwe.

Jednak obecnie programowalny potok jest normą. Zatem sprzęt jest nastawiony na programowalny potok. Utraciwszy początkową efektywność posiadania obwodu specjalnie utworzonego dla jednego określonego przepływu danych, musi on uwzględniać najczęstszy przypadek, jakim jest podejście oparte na module cieniującym. Jednak w przypadku opcji kompatybilności wstecznej potok funkcji stałych jest nadal dostępny - ale kosztem jest to, że stare stałe funkcje muszą zostać przekształcone w moduły cieniujące, co może wiązać się z dodatkowymi kosztami. To wyjaśniałoby różnicę w wydajności.

Głównym powodem, dla którego mogłem wymyślić, jest faza w ustalonym potoku, że twój program jej nie potrzebuje. na przykład wyobraź sobie grę, w której wszystkie światła są statyczne, możesz łatwo wdrożyć moduł cieniujący, który nawet nie próbuje obliczać dynamicznego światła. w tym przypadku moduł cieniujący działa szybciej niż moduł wstępnie skompilowany, który sprawdza niektóre równania pod kątem dynamicznego światła (moduł ogólnego przeznaczenia). są też inne przykłady, możesz łatwo wymyślić wiele aspektów, które należy wziąć pod uwagę dla stałego potoku, ale możesz zignorować implementację we własnych kodach GLSL.

Właśnie o to chodzi, twoje shadery zastępują części rurociągu. Ale często twoje programy cieniujące specjalizują się w osiągnięciu określonego efektu, który chcesz osiągnąć, i nie obsługują wszystkich możliwych specjalnych funkcji, które mogą być aktywowane, dlatego są prostsze niż moduł cieniujący, który emuluje pełny potok o stałej funkcji. Podczas gdy ścieżka o stałej funkcji musi uwzględniać wiele rzeczy i funkcji OpenGL, z których możesz nie chcieć korzystać (o których nawet nie słyszałeś).

A dni, w których stała funkcja była wykonywana na specjalnym sprzęcie (w przeciwieństwie do w pełni programowalnego sprzętu) minęły, co prawdopodobnie dzieje się, gdy używasz potoku o stałej funkcji, że Twój sterownik ładuje tylko własne specjalne moduły cieniujące, które implementują ścieżki o stałej funkcji. Ale mogą być bardzo skomplikowane, aby zapewnić każdą funkcję oferowaną przez potok o stałej funkcji.