Pomimo postępów współczesne procesory graficzne wciąż mają stałe rasteryzatory. Wysoce konfigurowalny, z programowalnymi modułami cieniującymi, ale mimo to nie w pełni programowalny.

Dlaczego?

Dlaczego procesory graficzne nie mogą być po prostu masowo równoległymi urządzeniami z uniwersalnymi jednostkami obliczeniowymi, w których rasterizer to tylko oprogramowanie dla tego urządzenia dostarczone przez użytkownika?

Czy posiadanie sprzętu o stałej funkcji jest tak korzystne pod względem wydajności, że takie podejście jest niewykonalne?

Krótko mówiąc, ze względu na wydajność nie można ich programować.

Historia i rynek

W przeszłości istniały oddzielne rdzenie dla procesorów wierzchołków i fragmentów, aby uniknąć rozdętych układów FPU. Niektóre operacje matematyczne można było wykonać tylko na przykład w kodzie modułu cieniującego fragmenty (ponieważ były one w większości istotne tylko w przypadku modułu cieniującego fragmenty). Spowodowałoby to poważne wąskie gardła sprzętowe dla aplikacji, które nie maksymalizowały potencjału każdego rodzaju rdzenia.

Gdy programowalne shadery stały się bardziej popularne, wprowadzono uniwersalne jednostki. Coraz więcej etapów potoku graficznego zostało zaimplementowanych w sprzęcie, aby pomóc w skalowaniu. W tym czasie GPGPU również stało się bardziej popularne, więc dostawcy musieli włączyć niektóre z tych funkcji. Nadal ważne jest, aby pamiętać, że większość dochodów z GPU to wciąż gry wideo, więc nie mogło to zakłócać wydajności.

W końcu duży gracz, Intel, postanowił zainwestować w programowalne rasteryzatory o architekturze Larrabee . Ten projekt miał być przełomowy, ale wydajność najwyraźniej była mniejsza niż pożądana . Został zamknięty, a jego części zostały uratowane dla procesorów Xeon Phi. Warto jednak zauważyć, że inni dostawcy tego nie wdrożyli.

Próby rasteryzacji oprogramowania

Podjęto pewne próby rasteryzacji za pomocą oprogramowania, ale wszystkie wydają się mieć problemy z wydajnością.

Jednym znaczącym wysiłkiem była próba Nvidii w 2011 roku w tym artykule . Zostało to wydane blisko kiedy Larrabee został zakończony, więc jest bardzo możliwe, że była to odpowiedź na to. Niezależnie od tego, istnieją pewne dane dotyczące wydajności, a większość z nich wykazuje wydajność wielokrotnie wolniejszą niż sprzętowe rasteryzatory.

Problemy techniczne z rasteryzacją oprogramowania

W artykule Nvidii pojawiło się wiele problemów. Oto niektóre z najważniejszych problemów z rasteryzatorami oprogramowania:

Główne problemy

• Interpolacja: Implementacja sprzętowa generuje równania interpolacyjne w specjalistycznym sprzęcie. Jest to powolne w przypadku renderera oprogramowania, ponieważ trzeba było to zrobić w module cieniującym fragmenty.

• Wygładzanie: Wystąpiły również problemy z wydajnością wygładzania (szczególnie z pamięcią). Informacje dotyczące próbek subpikseli muszą być przechowywane w pamięci na chipie, co nie wystarcza do ich przechowywania. Julien Guertault zwrócił uwagę, że buforowanie / buforowanie tekstur może być wolniejsze w przypadku oprogramowania. MSAA z pewnością ma tutaj problemy, ponieważ przepełnia pamięć podręczną (pamięci podręczne bez tekstur) i przechodzi do pamięci układu. Rasteryzatory kompresują dane przechowywane w tej pamięci, co również pomaga w wydajności.

• Zużycie energii: Simon F wskazał, że zużycie energii będzie niższe. W dokumencie wspomniano, że niestandardowe jednostki ALU znajdują się w rasteryzatorach (co zmniejszyłoby zużycie energii), i miałoby to sens, ponieważ jednostki przetwarzania fragmentów i wierzchołków w przeszłości miały niestandardowe zestawy instrukcji (więc prawdopodobnie również niestandardowe jednostki ALU). Z pewnością stanowiłoby to wąskie gardło w wielu systemach (np. Mobilnych), choć ma to wpływ na wydajność.

streszczenie

TL; DR: istnieje zbyt wiele nieefektywności, których renderowanie oprogramowania nie jest w stanie przeoczyć, a te rzeczy się sumują. Istnieje również wiele większych ograniczeń, szczególnie w przypadku przepustowości VRAM, problemów z synchronizacją i dodatkowych obliczeń.