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

27

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?

Joey Green
źródło
Czy pytasz, czy szybciej jest tworzyć własne wersje istniejących funkcji, czy też szybciej odciążyć funkcje obliczane na procesorze?
MichaelHouse
Znalazłem post na gamedev.net, który odpowiada na moje pytania.
Joey Green,
2
Widzę. Powinieneś opublikować odpowiedź na ten temat tutaj, aby inni mogli skorzystać. Być może wyjaśniając swoje pytanie w tym procesie.
MichaelHouse
@ joey-green, czy możesz połączyć link tutaj gamedev.net . Byłbym pomocny dla osób, które natkną się na to pytanie.
Quazi Irfan,
1
Aby bardziej pomylić sprawy, w moich testach ustalony potok może faktycznie być szybszy niż shadery, przynajmniej w prostych przypadkach; patrz sol.gfxile.net/instancing.html
Jari Komppa

Odpowiedzi:

27

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.

Dosyć
źródło
1
Dobra odpowiedź ... +1.
Amir Zadeh
@Green Nie jestem tego pewien. Jakoś mija się z celem. Odpowiedź Kylotana jest znacznie bardziej odpowiednia do rzeczywistego pytania.
Chris mówi Przywróć Monikę
14

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.

Kylotan
źródło
1

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.

Ali1S232
źródło
1

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.

Chris mówi Przywróć Monikę
źródło
„prawdopodobnie podczas korzystania z potoku o stałej funkcji jest to, że sterownik ładuje tylko własne specjalne moduły cieniujące, które implementują ścieżki o stałej funkcji”. ..jesteś tego pewien? Czy możesz podać jakieś wiarygodne źródło? Dzięki.
Quazi Irfan,
@iamcreasy Nie mam wiarygodnego źródła (dlatego prawdopodobnie), muszę przyznać. Ale mocno wątpię, że obecnie karty graficzne (które są tylko garstką wielu małych procesorów) nadal mają dedykowany sprzęt do obliczeń oświetlenia lub obliczeń mgły. Zamiast tego jest bardziej prawdopodobne, że po prostu ładują wstępnie skompilowane programy do określonych etapów shadera (czy pochodzą one ze sterownika, czy z pamięci ROM, nie wiem).
Chris mówi Przywróć Monikę
@iamcreasy według nouveau wiki nouveau.freedesktop.org/wiki/CodeNames , naprawiono potok w GeForce 6xxx.
DirtY iCE
„prawdopodobnie podczas korzystania z potoku o stałej funkcji jest to, że sterownik ładuje tylko własne specjalne moduły cieniujące, które implementują ścieżki o stałej funkcji”. Prawdziwe. „Ale mogą być bardzo skomplikowane, aby zapewnić każdą funkcję oferowaną przez potok o stałej funkcji”. Dobry sterownik wygeneruje moduły cieniujące tylko dla włączonej funkcjonalności.
Chris,