AMD Graphics Core Next: revoluční grafické jádro - část 1.

Minulá kapitola byla věnována vektorovému SIMD procesoru, který je takovou základní součástí architektury AMD Graphics Core Next a nyní se podíváme o úroveň výše na tzv. Compute Unit (výpočetní jednotka). Jak jsme si již řekli, vektorová SIMD dokáže vykonávat běžné vektorové informace a tím její funkcionalita v podstatě končí. V případě, že jednotlivé SIMD procesory zkombinujeme s dalšími funkčními jednotkami, získáme jednotku, v našem případě Compute Unit, která je schopna široké škály výpočetních úkonů. Compute Unit v tomto případě prakticky nahrazuje SIMD blok známý z Caymanu, který sdružoval jednotlivé stream procesory. Na rozdíl od starší architektury je Graphics Core Next schopno plnit výpočetní úlohy, o kterých se SIMD Caymanu může zdát pouze v těch nejdivočejších snech.

V případě Compute Unit je její složení poměrně jasné a skládá se z 4 SIMD vektorových procesorů, což není nepodobné Caymanu, ale v tomto případě Compute Unit zvládne najednou vykonat 4 instrukce. Součástí této jednotky je i logika pro dekódování, fetching, plánování instrukcí, které budou vykonávány. Jednotka dále obsahuje jako novinku samostatnou paměť o kapacitě 64 kB a L1 cache 16 kB, která je nyní společná pro data i jako texturovací cache. Malá kapacita pro obě úlohy by mohla znamenat problém, ale v samotné cache jsou uchovávány komprimované texely, takže pohroma je tím zažehnána. Compute Unit má ovšem další jednotky, které musíme zmínit a mezi ně patří skalární ALU.
Nyní se opět vrátíme trochu zpět, abychom mohli blíže pochopit funkcionalitu Compute Unit jako celku a přítomnost některých výpočetních jednotek, jako je už výše zmiňovaná skalární výpočetní jednotka. Musíme si trochu více osvětlit, co vede AMD k tomu, že chce upustit od VLIW architektury a přejít na klasickou SIMD architekturu. Slabinou VLIW architektury je statické plánování tohoto, co bude v rámci kódu vykonávat a vše stojí na kompilátoru. V případě, že ve vykonávaném kódu objeví nějaké závislosti, už bohužel nejde v podstatě nic změnit a slot VLIW SIMD zůstane nevyužitý. V tomto případě, je třeba přikročit k tomu, že plánování vykonávání jednotlivých souborů instrukcí (wavefront) se od softwarového kompilátoru přesune přímo do hardware.

Samozřejmě, když přesunete plánovací jednotku (scheduler) přímo do hardware, respektive do jádra čipu, bude vás to stát místo, které se v tomto případě platí zlatem. Když se podíváme do historie na čip ATI R300, který měl také VLIW architekturu, byť podstatně omezenější (co-issue a dual-issue) než pozdější čipy jako R600, tak zde platí, že v té době kompilátor odvedl v případě grafiky svou úlohu velmi dobře a uspořené místo se mohlo využít pro funkční výpočetní jednotky. Takže když přesunete plánování v zájmu jeho dynamičnosti přímo do hardware, je to vykoupeno menší plochou využitelnou pro výpočetní jednotky.

Nyní si přiblížíme scénáře, kde bude mít dynamické plánování a nezávislé SIMD procesory podstatně navrch oproti VLIW architektuře a softwarovému kompilátoru. K nejhoršímu možnému případu u architektury VLIW dojde tehdy, pokud jsou naplánované instrukce (wavefronts) na sobě kompletně závislé a zablokují se v řadě před sebou i v řadě za sebou, což je způsobeno tím, že musíte vykonat v řadě pouze ony. VLIW architektuře ujede pevná půda pod nohama a výkon jde rapidně dolů. V případě Graphics Core Next sice nemůžete vykonávat instrukce mimo naplánovaný program, neboť se nejedná o tzv. out-of-order architekturu a zapomenout můžete např. na vykonávání různých častí shaderů, jak by se vám v danou chvíli hodilo. Na druhou stranu v případě Compute Unit můžete zvolit odlišný wavefront (třeba i z jiné úlohy) a začít na něm pracovat.
V případě Caymanu a jeho VLIW architektury máte smůlu v případě, že byste rádi pracovali současně na různých úlohách. V případě stejné úlohy ve zpracování jednotlivých wavefronts nemáte problém, ale v případě odlišných úloh jste zase limitováni ze strany API, což je v našem případě DirectX. Graphics Core Next může pracovat na odlišných úlohách snadno a jediným limitem je, že každá SIMD má na výběr z 10 wavefronts, což znamená, že každá Compute Unit může vybírat a zpracovávat ze 40 wavefronts za běhu. Máme zde tedy možnost výběru z různých souborů instrukcí a zároveň máme hardwarovou jednotku pro dynamické plánování přímo v čipu, a to znamená žádné nevyužité ALU. Tento fakt je asi tím klíčovým, který vedl AMD k ústupu od VLIW architektury, která není vůbec špatná, ale od od GPU čipů se v budoucnu očekává podstatně více, než akcelerace grafiky.

Kompilátor samozřejmě nezmizí úplně, bude stále potřeba, ale jeho činnost bude osvobozena od plánování úloh a stane se spíše „podavačem“ těch správných soust pro hardware, tak jako je tomu u většiny jiných architektur. Otevírá se tím i prostor pro jiné programovací platformy a využití Graphics Core Next jako akcelerátoru. Bez nutnosti vytváření dlouhých VLIW instrukcí nebo bez „přibalování“ informací o plánovaném vykonávání bude vše podstatně jednodušší.

Nyní už máme alespoň základní přehled o tom, co se v případě architektury s plnohodnotnými vektorovými procesory Graphics Core Next děje a jaké jsou její výhody oproti současné architektuře VLIW u GPU Caymanu. Na začátku této kapitoly jsme ovšem zmiňovali skalární ALU a její funkce nám doposud zůstávala utajena. Vězte, že má na starosti operace, které by byly pro SIMD (zpracovává wavefronts – soubory instrukcí) neefektivní. Tato jednotka se skládá ze skalární ALU a 8kB register file.

Tato jednotka má na starosti vykonávání jedinečných matematických operací. Je to tedy tak, že skupiny pixelů/hodnot jdou skrz vektorové jednotky společně, ale nezávislé operace mohou bez problémů využít dostupnou skalární ALU a neničí tak plánování jednotlivých wavefronts a potažmo efektivitu a výkon Compute Unit. Když mluvíme o jedinečných matematických operacích, tak tím zde myslíme vše od jednoduchých celočíselných operací po podmínkové operace if/else (větve), skoky v shaderu a v některých případech také „read-only“ paměťové operace z dedikované L1 cache. V případě jedné Compute Unit může být v cyklu, kdy je zpracována jedna wavefront, vykonána čtveřice těchto operací díky 4 samostatným skalárním ALU.

Díky této kombinaci vektorových procesorů a skalární ALU by se teoreticky Graphics Core Next dala označit za hybrida, protože poněkud smazává rozdíly mezi vektorovými a skalárními architekturami. Přítomnost skalární ALU má také další pozitivum, kterým je snížení latence v případě tzv. „control flow“ operací. Control flow jsou operace, kdy např. voláte nějakou funkci, nebo vykonáváte skok kódu, či vykonáte ověření podmínky (if/else). Cayman s VLIW architekturou měl v tomto případě latenci 44 cyklů, takže dost příšerné číslo alespoň dle AMD. Jaká hodnota budou alespoň teoreticky platit pro Graphics Core Next prozatím nevíme.

Konec první části - navazovat bude díl druhý, který osvětlí další podrobnosti architektury AMD Graphics Core Next

Zdroje: Anandtech, Wikipedia, AMD