Do tej pory udało mi się dowiedzieć, że nastąpiło przejście od bardzo wyspecjalizowanego obiegu, który wdraża różne etapy potoku graficznego, do bardziej ogólnego podejścia. Ta transformacja została częściowo odzwierciedlona w interfejsach API 3D w postaci programowalnych shaderów. Większość tranzystorów wydaje się być dedykowana do masowo równoległych jednostek SIMD, które wykonują rzeczywiste instrukcje modułu cieniującego.
Poprawny. Zasadniczo, ze względu na stosunkowo duży rozmiar funkcji na starszych GPU, jedynym sposobem na efektywne wdrożenie takich rzeczy jak podstawowe oświetlenie, antyaliasing, mapowanie tekstur, geometria itp. Było użycie potoku „stałej funkcji”. Poświęcili elastyczność ze względu na wydajność, ponieważ nie mieli wystarczającej gęstości układów, aby móc ją wdrożyć przy użyciu bardziej ogólnej, masowo równoległej architektury SIMD, takiej jak obecne układy GPU.
Jest nowoczesnym GPU (myśl Nvidia Fermi) w zasadzie zestaw „głupich” macierzy SIMD, które są zasilane instrukcjami i danymi z procesora i różnych pamięci podręcznych, a cała logika, która odwzorowuje potok grafiki na te instrukcje, dzieje się w sterowniku graficznym ?
Niektóre rzeczy są nadal wykonywane w sprzęcie; inni nie są. Na przykład, ROP są nadal używane na ostatnim etapie do przesyłania danych pikseli do mikroukładu VGA. Uwaga Używam tutaj „mikroukładu VGA” jako ogólnego terminu odnoszącego się do mechanizmu, który przesyła sygnał wideo do twojego monitora, niezależnie od tego, czy pod każdym względem jest to rzeczywiście „VGA”.
Prawdą jest, że obecne architektury GPU, takie jak Nvidia Fermi i AMD Southern Islands, są w większości masywnie równoległymi procesorami, w których mają niestandardowy zestaw instrukcji, a każdy „rdzeń” jest wyjątkowo słaby, ale istnieją całość wiele rdzeni (czasem kilka tysięcy). Ale wciąż jest tam sprzęt specyficzny dla grafiki:
Sprzętowe dekodowanie wideo jest często wykonywane, w dużej części, przy użyciu układów o stałej funkcji. Dotyczy to w szczególności DRM (Digital Restrictions Management). Czasami „sprzętowe” dekodowanie wideo naprawdę oznacza zestaw instrukcji kierowanych przez oprogramowanie układowe, które są po prostu podawane jako zwykłe stare zadania dla rdzeni SIMD. To naprawdę zależy.
Z wyjątkiem bardzo niewielu kart Nvidia specyficznych dla obliczeń (Tesla), prawie wszystkie karty graficzne „generic SIMD” mają pełną gamę sprzętu dedykowanego do wyjścia wideo. Wyjście wideo to nie to samo, co renderowanie; elementy wyjściowe o stałej funkcji obejmują kodeki LVDS / TMDS / HDMI / DisplayPort, HDCP, a nawet przetwarzanie audio (w zasadzie trochę DSP), ponieważ HDMI obsługuje audio.
„Pamięć graficzna” jest nadal przechowywana na pokładzie z procesorami graficznymi, dzięki czemu nie muszą przechodzić przez gadatliwą i stosunkowo opóźnioną magistralę PCIe, aby uderzyć w systemową pamięć RAM, która sama jest wolniejsza i zajmuje więcej czasu niż droższa, wyższa jakość, szybsza pamięć graficzna (np. GDDR5), która ma mniejsze pojemności, ale wyższe prędkości niż pamięć systemowa. Proces przechowywania rzeczy w pamięci graficznej i pobierania ich stamtąd do procesora graficznego lub procesora jest nadal w zasadzie operacją o ustalonej funkcji. Niektóre procesory graficzne mają swój własny „IOMMU”, ale ta jednostka zarządzania pamięcią różni się (osobna) od procesora. Nie dotyczy to jednak najnowszych procesorów graficznych Intel zintegrowanych z ich procesorami (Sandy i Ivy Bridge), w których architektura pamięci jest prawie całkowicie „spójna” pamięć systemowa) i odczyty z pamięci graficznej są tak samo tanie dla procesora, jak i dla procesora graficznego.
A może gdzieś w GPU są jakieś jednostki sterujące, które tłumaczą przychodzące instrukcje wysokiego poziomu i strumienie danych (skompilowane programy cieniujące, dane i atrybuty wierzchołków oraz tekstury) na rzeczywiste instrukcje SIMD i zajmują się synchronizacją, alokacją pamięci itp.?
„Natywny” język kart SIMD jest prawie zawsze generowany przez sterownik w oprogramowaniu, a nie przez własne oprogramowanie układowe GPU. Jest to szczególnie prawdziwe w przypadku funkcji poziomu DirectX 9 / OpenGL 2.x. Moduły cieniujące napisane w językach wysokiego poziomu, takich jak HLSL, GLSL lub OpenGL ARB asembler, są ostatecznie tłumaczone przez sterownik na instrukcje GPU poprzez uderzanie w określone rejestry i wykonywanie wymaganych pętli PCIe w celu przesyłania buforów wsadowych obliczeń i / lub renderowania polecenia.
Kilka rzeczy, takich jak teselacja sprzętowa (DirectX 11 / OpenGL 4.0), jest ponownie wpychanych do sprzętu w sposób o stałej funkcji, podobnie jak robili prawie wszystko w dawnych czasach. Wynika to z tego, że ograniczenia wydajności wymagają, aby najbardziej wydajnym sposobem wykonywania tych obliczeń było posiadanie dedykowanego zespołu obwodów, zamiast oprogramowania wewnętrznego lub sterownika „programującego” karty SIMD w tym celu.
Podejrzewam, że rzeczywistość leży gdzieś pomiędzy tymi dwiema skrajnościami, a odpowiedź byłaby raczej długa i oparta na wielu spekulacjach (musi istnieć powód, dla którego niektórzy dostawcy GPU odmawiają publikacji jakiejkolwiek dokumentacji na temat swoich produktów, nie mówiąc już o sterowniku kod źródłowy ...), ale wszelkie wskazówki we właściwym kierunku i przydatne zasoby będą mile widziane.
AMD i Intel mają bardzo solidną dokumentację na temat swoich najnowszych układów GPU, a także w pełni działające sterowniki graficzne typu open source dla systemu Linux (patrz projekty Mesa i Direct Rendering Manager). Jeśli spojrzysz na część kodu w tych sterownikach, będziesz się śmiać, ponieważ autorzy sterowników graficznych faktycznie muszą zaimplementować geometrię takich rzeczy, jak rysowanie różnych kształtów lub wzorów, w „oprogramowaniu” (ale za pomocą poleceń sprzętowych, aby przesłać prawdziwe pracy nad sprzętem do przetwarzania), ponieważ ani oprogramowanie układowe GPU, ani sprzęt stały nie jest już obecny, aby w pełni przetworzyć go sprzętowo :) To zabawne, co muszą zrobić, aby obsługiwać OpenGL 1.x / 2.x na nowym sprzęt komputerowy.
Ewolucja potoczyła się tak:
- Bardzo dawno temu (zanim rendering 3D w czasie rzeczywistym uznano za możliwy): Śledzenie promieni na procesorze było normalne w przypadku renderowania w czasie rzeczywistym. W przypadku prostych grafik, takich jak we wczesnych wersjach systemu Windows, procesor był wystarczająco szybki, aby narysować proste kształty (prostokąty, znaki czcionki, wzory cieniowania itp.) Bez ustalonego sprzętu, ale nie mógł narysować zbyt skomplikowanych rzeczy.
- Dawno temu (OpenGL 1.x): prawie wszystko implementowane przez sprzęt półprzewodnikowy; „elektrycznie” ustalone funkcje były normą nawet dla podstawowych operacji
- Jakiś czas temu (OpenGL 2.x): Rozpoczęło się przejście do uczynienia GPU bardziej programowalnymi. „Fragment shadery” (aka shadery pikseli) na 5-letnim sprzęcie mogą prawie wykonywać dowolne obliczenia jak procesor, ale jest to ograniczone przez architekturę, która jest nadal bardzo ukierunkowana na grafikę. Dlatego OpenCL / DirectCompute nie są dostępne na tym sprzęcie.
- Niedawno (OpenGL 3.x): Przejście na procesory graficzne ogólnego przeznaczenia jest w większości zakończone, ale są one oczywiście zoptymalizowane do obciążeń związanych z przesyłaniem dużych macierzy danych (myśl algebry liniowej) w partiach, a nie procesorów, które mogą skutecznie działać na długie sekwencje bardzo małych danych (kolejno 1 + 1, 2 * 4, 5 * 6 itd.) Obliczenia ogólnego przeznaczenia są dostępne przez OpenCL, CUDA itp., ale sprzęt nie jest jeszcze w pełni „koprocesorem SIMD” ponieważ (a) nadal trzeba wbijać rejestry specyficzne dla sprzętu, aby uzyskać dostęp do funkcji GPU; (b) odczyt z VRAM GPU jest bardzo wolny z powodu narzutu magistrali PCIe (odczyt z GPU nie jest bardzo zoptymalizowany w obecnej architekturze); (c) architektura pamięci i pamięci podręcznej nie jest spójna z procesorem; wciąż istnieje wiele starszych urządzeń ze stałymi funkcjami.
- Obecny (OpenGL 4.x): Pozbyłem się dużo starszego sprzętu o stałej funkcji. Poprawiono nieco opóźnienie odczytu karty graficznej. IOMMU umożliwiają (przetłumaczone) mapowanie wspomagane sprzętowo między VRAM a pamięcią systemową. Wprowadzono teselację sprzętową, przywracając elementy stałej funkcji.
- Przyszłość ( HSA): GPU jest w zasadzie koprocesorem. Jest prawie całkowicie zintegrowany z procesorem z bardzo małą impedancją (do odczytu / zapisu) między GPU a CPU, nawet dla dedykowanych GPU na magistrali PCIe. W pełni spójna architektura pamięci - „mi memoria es su memoria” (moja pamięć to twoja pamięć). Programy przestrzeni użytkownika mogą odczytywać z „VRAM” tak samo, jak odczytują z pamięci systemowej bez sterownika, a sprzęt się tym zajmuje. Masz procesor do przetwarzania „szeregowego” (zrób to, a następnie zrób to, a następnie zrób to) dla skromnych ilości danych, a procesor graficzny do przetwarzania „równoległego” (wykonaj tę operację na tym ogromnym zestawie danych i podziel go jak widzisz dopasowanie). Płyta, na której siedzi GPU, może nadal mieć ROPy, kodek HDMI itp., Ale te rzeczy są niezbędne do wyświetlania obrazu,