Naszedł czas zająć się drugim sercem chipów SoC – układem graficznym. Niemniej bierzcie pod uwagę, że jest to temat rzeka, opisywany przez doktorów całymi encyklopediami.

Mało tego większość producentów strzeże tajemnic wewnętrznej budowy GPU niczym Templariusze swego skarbu. Wiele informacji, na które natkniecie się w Internecie jest błędnych lub nawet celowo zafałszowanych. Postaram się przybliżyć temat możliwie najdokładniej jak się da. Ostrzegam jednak że czytania sporo, bo niniejszy artykuł to próba syntezy i streszczenia tysięcy stron i publikacji, więc cierpliwość jest koniecznością.

Pierwszą część mojego felietonu możecie przeczytać tutaj.

O tym jak nas oszukują, a my dajemy się dmuchać…

liar

Niestety taka jest rzeczywistość i najsmutniejsze w tej sytuacji jest to że im na to pozwalamy. Niewiedza sprzedawców, czy dziennikarzy nie jest tutaj żadnym wytłumaczeniem, bo na tym polega ich praca. Jedni muszą wiedzieć o czym piszą, a drudzy muszą wiedzieć co sprzedają. Niestety chciwość bierze górę, a przykład A31 i RK3188 jest wręcz idealny aby to zobrazować. Wojna na rdzenie stała się coraz bardziej intensywna i została przeniesiona z CPU na GPU. Sprzedażowa propaganda “rdzeni”, “wątków”, “MP4”, “ilości trójkątów”, „szybkość wypełniania pikseli” ma na celu przyciągnąć klienta i przekonać go o słuszności dokonanego wyboru pomijając istotne fakty.

Kto co robi

Dyskusję na temat GPU w Soc’ach trzeba zacząć od zrozumienia zasady ich działania. W przeciwieństwie do zestandaryzowanych architektur ARM, nie ma tutaj żadnych reguł i panuje wolna amerykanka. Rozwiązań dla rynku mobilnego dostarczają głównie:

  • ARM Holdings z serią Mali,
  • Imagination Technologies (wywodzacy się z NEC) z serią PowerVR,
  • Vivante Corporation z serią GC
  • Qualcomm Incorporated z serią Adreno ( przemyślnie kupionym od AMD/ATI)
  • Nvidia z serią ULP GeForce.

ciasto+watermark

Oczywiście są inni jak S3 czy Broadcom, aczkolwiek pominięci i zapomniani bo wypadli z rynku. Postaram się przybliżyć architekturę tych układów, które aktualnie kreują rynek.

GPU czyli co?

cubeGPU to graficzna jednostka przetwarzająca. Większość z was kojarzy ten skrót z kartami graficznymi ale w naszych tabletach jest to poukładane trochę inaczej. GPU jest wbudowane w SoC na stałe i stanowi integralną część kości. Jego rolą jest generowanie obrazu 3D, bo CPU Cortex-A po prostu sobie z tym nie radzą. Oczywiście mogą to emulować z ogromną stratą mocy. Praktycznie każde GPU wspomaga wyświetlanie 2D, takie jak animacje pulpitu czy zbliżanie/oddalanie, ale o tym decyduje już sam system.

API

OpenGL_ES_logoAPI, czyli interfejs programowania aplikacji – protokół spełniający dany standard i używany do komunikacji systemu z innymi komponentami i modułami programowymi. Najważniejsze są dwa ogólnie przyjęte standardy: DirectX i OpenGL. Pierwszy oczywiście wspiera platformy Windows, bo tak jak on jest własnością Micorsoft’u i dotyczy to wszystkich odmian Direct’a. Drugi to biblioteki otwarte działające na zasadzie open source – dostępne do modyfikacji dla wszystkich i wspierające Androida: OpenGL ES (biblioteki graficzne 3D), OpenCL (biblioteki framework wspierające architekturę heterogeniczną) i OpenVG (biblioteki wektorowe 2D). Istnieje specjalna organizacja – Khronos Group – zrzeszająca praktycznie wszystkich producentów sprzętu i dbająca o jednolity standard bibliotek wprowadzonych jako oficjalne produkty i przeznaczonych dla nas, użytkowników końcowych.

Stacjonarne vs. mobilne

Chciałbym też podkreślić wyzwania jakie stoją przed projektantami GPU w Soc’ach. Tutaj krótkie porównanie.

[table caption=”Porównanie GPU w SoC” colalign=”left|center|center|center”]
SoC,TDP,Pmax, Powierzchnia
OMAP 4460 1.2 GHz z PowerVR SGX540, 0.6 W, 7.2W, 166 mm2
Radeon 6970 w moim blaszaku :), 207 W, 361 W, 389 mm2
[/table]

TDP – ilość wydzielanego ciepła, które musi zostać odebrane z układu
Pmax – szczytowe zużycie prądu
Z powyższego widać, że Soc wydziela 345 razy mniej ciepła, zużywa 50 razy mniej energii i zajmuje połowę powierzchni. Najważniejsze jest to, że Radeon 6970 jest tylko kartą graficzną, a OMAP4460 kompletnym systemem. Wydajności nawet nie porównuję, bo Radek rozbiłby OMAP’a na atomy. Poniżej mały schemat podkreślający różnice między platformami.

mob_stac+watermark
Zauważcie jak mocno producenci GPU do Soc’ów są ograniczeni przepustowością pamięci nawet pomimo zastosowania szerokiego, bo 64-bitowego pasma. To nie problem wstawić 16 rdzeniowe GPU, pod warunkiem jednak, że ma się je jak wykarmić danymi do przetwarzania. Jedynie Apple w chipie A6X zamontował 128-bitową szynę i pamięci LPDDR2-1066 o przepustowości do 17GB/s aby potężne czterordzeniowe PowerVR554 SGXMP4 nie umarło śmiercią głodową.

„Wątek graficzny”

Poniższy schemat (mocno uproszczony) przedstawia po kolei jak linijki kodu zamieniają się w kolorową animację. Jak widzicie zaznaczyłem na nim skąd biorą się magiczne liczby we wszystkich „profesjonalnych” tabelkach porównujących produkty.

pipeline+watermark

Pierwsze schody

Jeśli myślicie że powyższy schemat ma zastosowanie w każdej architekturze to muszę was bardzo mocno rozczarować. Generalnie można sklasyfikować trzy różne tryby renderowania scen w architekturach mobilnych:

IMR_TBR_TBRD+watermark

Powyższe różnice, choć z punktu widzenia schematu są nieznaczne, to wprowadzają szereg zmian w sposobie optymalizacji programowania jak i samego renderowania. W trybie IMR pracują układy Vivante oraz Nvidia (tak samo wygląda to na komputerach stacjonarnych). Niestety aby było to wydajne, potrzebna jest bardzo duża przepustowość pamięci, co kuleje wyraźnie mocno w serii GC. Nvidia radzi sobie lepiej przez zastosowanie dyskretnych skalarnych shader’ów, o czym później. Układy Mali oraz Adreno pracują w trybie TBR, a PowerVR w trybie TBDR.

Kładziemy kafelki

Na czym polega TBR i czym się różni od nich TBDR? Kafelkowaniem nazywa się podział renderowanej sceny na małe fragmenty. Powód takiego działania jest dość prosty, mianowicie obrabia się o wiele mniejszą ilość danych, czyli drastycznie zmniejsza się zużycie pamięci. O ile Mali i PowerVR działają na małych kafelkach, zazwyczaj odpowiednio 16×16 pikseli, 32×32 piksele, Adreno używa relatywnie dużych, czyli 128×128/256×256 pikseli.

tiling+watermarkDokładny wymiar kafelków w PowerVR i Adreno jest zmienny, w zależności od konkretnego SoC’a (architektura GPU PowerVR, tak jak ARM, też jest sprzedawana jako licencja). Większy wymiar kafelków pozwala Adreno obrabiać większą ilość danych przy mniejszym opóźnieniu spowodowanym zapisami/odczytami z cache’u GPU, ale taka pamięć słono kosztuje: i finansowo i energetycznie.

TBDR vs. TBR

tbr-tbdr+watermark

TBDR jest ulepszonym TBR, wykonującym dodatkowe czynności, m.in. HSR (Hidden Surface Removal – usuwanie niewidocznych powierzchni). Ta technika pozwala całkowicie rozwiązać problem Overdrawing’u (nadrysowywania), przez usunięcie powierzchni ukrytych w danej scenie przez inne obiekty na podstawie samych wierzchołków, niezależnie od kolejności składania. Technologia powstała i została opatentowana jeszcze w czasach kiedy Imagination Technologies walczyło o rynek stacjonarnych GPU z Nvidią i ATI. Mało kto zwrócił wtedy uwagę na to, że HSR tak przyspieszyło działanie kart graficznych, że przebijało o niebo konkurencję. Niestety ze względu na brak wsparcia technologii T&L (Transformation and Lighting – transformacja i oświetlenie) zaliczyli fiasko.

„Czterordzeniowe” Mali400MP4 vs „Ośmiordzeniowy” PowerVR544MP2

Czyli jak to jest naprawdę z tymi rdzeniami. Na początek zdjęcie jednego i drugiego układu GPU (niestety nie udało mi się zdobyć fotek RK3188 i A31, więc będę się posiłkował innymi, podobnymi Soc’ami).

a5-4212+watermark
Apple A5 (S5L8942X) z PowerVR SGX543MP2 vs Exynos4212 z Mali-400MP4

Obydwa układy zostały wykonane w technologii 32nm i wyposażone w dwurdzeniowe CPU Cortex-A9, więc możecie również porównać wielkość obydwu układów. Jak widać z powyższych zdjęć PowerVR ma „nieoszukane” dwa rdzenie fizyczne, tak jak w nazwie, i mogą one działać niezależne. SGX543MP od SGX544MP odróżnia tylko brak wsparcia dla DirectX10. Mali400MP4 ma za to cały jeden rdzeń fizyczny:) A więc skąd się wzięły magiczne wartości 8 i 4?

Tajemnice shader’ów

shader

Shader‘y obecne w GPU w SoC’ach można podzielić następująco:

  • zunifikowane potrafią przeprowadzać operacje zarówno vertex’owe (na wierzchołkach) jak i pixelo’we (kolor i przezroczystość)
  • dyskretne obsługują tylko jedną operację: albo Vertex’ową albo Pixel’ową.

Ich ilość i układ pokazuje w jaki sposób je przeprowadzają. W związku z używaniem w grafice koordynat wierzchołków (xyzw) oraz kolorów (RBGA) typowy układ SIMD to Vec4+1, czyli operacja na 4 wymiarowym wektorze plus jedna operacja arytmetyki skalarnej. Większość jednostek wykonuje na wektorach operacje typu MAD (multiply add – mnożenie dodawanie), nie dotyczy to arytmetyki skalarnej, która operuje na wartościach liczb rzeczywistych i zazwyczaj może wykonać tylko jedną operację. Oczywiście to że jest możliwość wykonania instrukcji Vec4+1, nie znaczy że zawsze się takie trafiają. Jeśli instrukcja jest krótsza, to moc najzwyczajniej w świecie zostaje zmarnowana. Poniżej schemat zunifikowanych shader’ów.

uklad shaderow+watermark

Garść „technikaliów”

IF

Taktowanie GPU często gęsto jest pomijane w danych technicznych a ma bardzo duże znaczenie, bo wydajność układu wzrasta proporcjonalnie do ilości Hertzów. Dla przykładu Vec4+1 może wykonać 9 FLOP’ów (operacji zmiennoprzecinkowych) w jednym cyklu (dla 1Hz). Dziewięć, bo dwie operacje dla każdego punktu plus jedna operacja skalarna, czyli 4 x 2 + 1. Jakby tego nie było dość, operacje zmiennoprzecinkowe są obliczane z różną precyzją. Na ten moment używane są trzy i wyraża się je w bitach: 10 (stała precyzja), 16 (pół precyzyjne), 32 (pojedynczej precyzji). Są oczywiście liczby o większej precyzji, ale nie dotarły jeszcze do świata GPU w Soc’ach (chociaż w stacjonarnych są od dawna).

Nie każda architektura wspiera wszystkie rodzaje precyzji i dlatego powstają problemy kompatybilności oprogramowania lub straty mocy obliczeniowej na dopełnienie precyzji (np. w przypadku Mali którego Pixel Shader nie obsługuje pojedynczej precyzji). Zaznaczam również że dla różnych precyzji, potrzeba różnych ilości cykli do wykonania obliczeń.

TMU – szara eminencja

tekstury+watermarkZmowa milczenia tyczy się również jednostek TMU – teksturująco-mapujących, mających za zadanie obrócić i przeskalować teksturę przed nałożeniem na obiekt 3D. Najpierw dostaje koordynaty wierzchołków, pobiera i obrabia teksturę, a następnie przesyła ją do piksel/vertex shader’a. To zadanie jest bardzo ciężkie i wymaga sporej mocy obliczeniowej. Istnieje też wiele rodzajów kompresji tekstur. Najpopularniejszy jest format ETC1 (Ericsson) oraz S3TC (S3, nazywany również DXTn, DXTC, BCn).

Obecnie Android ma problem ze wspieraniem innych standardów niż ETC1. Z ważniejszych należy wymienić również ATITC (ATI, stosowany w Adreno) oraz PVRTC i PVRTC2 (PowerVR), które nie dość że działają szybko i dobrze wyglądają, to znacznie ograniczają rozmiar tekstury (jak PVRTC 1 i 2) i przez to zmniejszają ogólne obciążenie GPU. Głównie stąd bierze się szybkość aplikacji iOS, pracującego na PVRTC, który potrafi zaoszczędzić o 8-16 razy mniej pamięci. Przykład kilku rodzajów kompresji:

kompresja

Wyciskanie SoC’u z 3D

soczek+watermark

Z poniższego możecie wyczytać, że producenci GPU skupiają się na bardzo różnych aspektach przy projektowaniu GPU. Do ilości generowanych texel’i oraz trójkątów trzeba podchodzić z rezerwą, zwłaszcza że prezentowane przez mnie wyniki to testy syntetyczne a nie prawdziwe gry i aplikacje 3D. Niestety na ten moment jest ich jak na lekarstwo. Z tymi wartościami wiąże się też pewna tajemnica, mianowicie są trójkąty, nie będące trójkątami i piksele, nie będące pikselami ale o tym może innym razem. Oto zestawienie najpopularniejszych obecnie GPU pokazuje możliwości każdego z nich.

tabelka+watermark

ARM Mali 400 MP4 vs. PowerVR SGX 544 MP2

fight

Magiczne „4 rdzenie” w Mali400MP4 to nic innego jak pixel/fragment shader’y. Przemilczany jest fakt używania dyskretnych Shader’ów, co jest przestarzałą metodą, która nie pozwala efektywnie zutylizować mocy GPU. Ze względu na jedną jednostkę geometryczną jest bardzo słabe wobec konkurencji jeśli chodzi o generowanie trójkątów. Za to wspomniane wcześniej cztery Pixel Shadery i cztery jednostki teksturujące pozwalają na wypełnienie pikseli ponad normę. Jeśli zoptymalizuje się grę pod Mali, może ona chodzić płynnie i zapewnić sporo efektów.

SGX544MP2 to klasa sama w sobie. Magiczne „8 rdzeni logicznych” oznacza osiem zunifikowanych shaderów, mogących przeprowadzić operacje zarówno na wierzchołkach jak i pikselach oraz cztery jednostki teksturujące. Należy dodać do tego ich technologię HSR, która wedle twórców zapewnia średnio 2,5 krotną oszczędność w wypełnianiu i możliwość zastosowania skompresowanych tekstur PVRTC. Pod względem możliwości budowy bardziej złożonych i skomplikowanych scen bije Mali na głowę trzy razy. Z moich obserwacji wynika również, że gry zoptymalizowane pod Mali działają szybciej średnio o 15-25% na SGX544MP2.

FatalityCóż… Mali Game Over – SGX „Flawless Victory”

To obiektywna ocena i nie jestem odosobnionym głosem w tym przypadku. Tacy giganci rynku jak Sony (PSP, Vita), Apple (wszystkie generacje), Intel (Clovertrail+), Texas Instruments (wszystkie OMAP’y), nawet Samsung (PowerVR zamiast Mali w Octa) zauważyli potencjał i chcą go wykorzystać. Aż zacieram ręce na myśl o tym co przyniesie ich nowe dziecko: architektura „Rouge”. Chodzą słuchy, że chcą nią przekroczyć barierę 1 TFLOPS (1000 GFLOPS).