V dnešní části seriálu o historii vývoje počítačových her a herního hardware dokončíme popis čtvrté významné konzole páté generace – Nintendo 64. Budeme se zabývat především čipem nazvaným Reality Co-Processor, který byl určen jak pro vykreslování 2D a 3D scén, tak i pro syntézu hudby a zvuků.
1. Historie vývoje počítačových her (111. část – Reality Co-Processor v herní konzoli Nintendo 64)
2. Interní struktura Reality Co-Processoru
3. Reality Signal Processor (RSP)
4. RSP jako jedna z mnoha implementací vektorového procesoru typu SIMD
7. Využití akumulátorů připojených ke každé ALU v RSP
8. Reality Display Processor (RDP)
V předchozí části tohoto seriálu jsme si popsali dva základní moduly herní konzole páté generace nazvané Nintendo 64. Jednalo se především o centrální procesorovou jednotku založenou na RISCovém jádru řady MIPS R4000. Tento mikroprocesor podporoval 32bitové i 64bitové operace a obsahoval i matematický koprocesor. Minule jsme si též popsali paměťový subsystém, v němž byly použity paměťové moduly s architekturou Rambus. Dnes se budeme převážně zabývat třetím důležitým čipem umístěným v této herní konzoli. Jedná se o čip nazvaný Reality Co-Processor, neboli zkráceně též RCP. V tomto čipu byl implementován především grafický a zvukový subsystém a pravděpodobně nejzajímavější vlastností RCP je jeho programovatelnost a konfigurovatelnost, což například znamená, že grafický subsystém (resp. vykreslovací pipeline s rasterizační jednotkou) bylo možné přeprogramovat, implementovat v něm různé grafické algoritmy a filtry, využít framebuffer jako texturu pro další vykreslování atd.
Z dnešního pohledu se jednalo o středně složitý čip s přibližně 2,6 miliony tranzistorů, jehož plocha byla přibližně 81mm2. Pro zajímavost: zhruba třetinu plochy čipu zabíral Display Processor (tj. konfigurovatelná vykreslovací/rasterizační jednotka řízená specializovanými příkazy), další třetinu zabraly paměti pro instrukce, data i textury a jen pětina plochy čipu byla rezervována pro vektorový procesor, jehož popisem se budeme zabývat v navazujících kapitolách. Hodinový signál čipu RCP byl nastaven na frekvenci 62,5 MHz, tj. frekvenci odlišnou od hodinové frekvence hlavního procesoru a jeho špičková spotřeba nepřesahovala 2,8W. Díky tomu bylo možné čip chladit pouze s využitím pasivního chladiče, podobně jako tomu bylo v případě hlavního mikroprocesoru. Komunikace mezi jednotlivými moduly tohoto čipu probíhala po interní 128bitové sběrnici, takže přenosová rychlost se blížila jednomu gigabajtu za sekundu (62,5×128/8).
Při návrhu interní struktury čipu RCP stáli jeho tvůrci před úkolem navrhnout takový čip, který by umožnil provádět syntézu hudby, dekódovat video a zobrazovat dvoudimenzionální i třídimenzionální grafické scény. Když se zamyslíme nad tím, co mají tyto čtyři činnosti společné, zjistíme, že většina algoritmů z těchto oblastí vyžaduje operace typické pro DSP procesory (sčítání se saturací, operace typu multiply-and-accumulate) a taktéž práci s vektory a maticemi. Reality Co-Processor byl následně navržen takovým způsobem, aby tyto operace podporoval, ovšem na druhou stranu nesměla být výrobní cena čipu příliš velká, protože by mohlo dojít k situaci, kdy by celá herní konzole Nintendo 64 byla dražší než herní konzole vyráběné konkurencí. Výsledkem snahy o „cenovou optimalizaci“ byl čip složený ze dvou modulů – Reality Signal Processor (RSP) a Reality Display Processor (RDP). Oba moduly byly široce konfigurovatelné a programovatelné a to dokonce do takové míry, že u RCP bylo možné měnit mikrokód na základě požadavků vývojářů hry.
Obrázek 1: Interní struktura a moduly čipu Reality Co-Processor.
Důležitý byl i fakt, že Reality Signal Processor (RSP) byl zaměřen na práci s vektory, protože kromě klasické ALU, shifteru, pracovních registrů a (od sebe oddělených) pamětí pro instrukce a data obsahoval tento modul i osm paralelně pracujících 16/32 bitových aritmeticko-logických jednotek, z nichž každá byla připojena k samostatnému 32bitovému akumulátoru. Navíc byl Reality Signal Processor vybaven instrukcemi pro načítání a automatickou konverzi osmibitových hodnot, což souběžně s podporou operací se šestnáctibitovými a 32bitovými hodnotami dostačovalo jak pro implementaci audio algoritmů (digitální filtry, syntéza hudby), tak i pro algoritmy z oblasti 2D i 3D grafiky. Druhý modul Reality Display Processor (RDP), jenž byl přímo řízen z RSP, byl určen pro vykreslování 2D a 3D scén. Jeho hlavním úkolem bylo vykreslování trojúhelníků či obdélníků, které mohly být buď vyplněny barvou nebo pokryty texturou. Dále tento modul mohl při vykreslování provádět různé další operace, například aplikace filtrů atd. Výsledek vykreslování (rasterizace) se ukládal do framebufferu.
V této kapitole si stručně popíšeme první modul čipu RCP, který se jmenuje Reality Signal Processor (RSP). Jedná se v podstatě o druhý samostatně pracující mikroprocesor založený na jádru MIPS R4000, podobně jako hlavní procesorová jednotka popsaná minule. Ovšem zatímco hlavní CPU dokázal provádět operace s 32bitovými i 64bitovými operandy, měl RSP poněkud odlišnou konfiguraci. Tento čip obsahoval 32bitové skalární pracovní registry a vlastní paměť pro data i instrukce – paměť pro data měla kapacitu 4kB a od ní oddělená paměť pro data měla tutéž kapacitu 4 kB. Pokud bylo zapotřebí pracovat s daty či instrukcemi umístěnými v hlavní paměti, musel být proveden přenos celého bloku dat s využitím DMA, protože RCP neměl do hlavní paměti přímý přístup, což je podobná koncepce, s jakou jsme se již několikrát setkali i u dalších herních konzolí páté generace (současně se však jedná i o úzké hrdlo celé konzole, což si ukážeme na příkladu texturovací jednotky).
Jedním z největších rozdílů mezi hlavní procesorovou jednotkou a modulem RSP bylo odstranění instrukcí pro práci s 64bitovými operandy i odstranění některých „pokročilejších“ instrukcí typu branch likely (opět viz předchozí část, kde jsou tyto instrukce z tohoto důvodu explicitně zmíněny) atd. Ovšem Reality Signal Processor byl naproti tomu obohacen o osm vektorových jednotek (Vector Unit – VU) pracujících paralelně, a to se vstupními operandy o šířce šestnáct bitů. Každá vektorová jednotka obsahovala vlastní aritmeticko-logickou jednotku (ALU), násobičku, shifter a taktéž 32bitový akumulátor, do něhož se ukládaly výsledky operací a který mohl sloužit i jako jeden vstupní operand (což znamená, že při vhodném naprogramování bylo možné provádět nejenom 16bitové operace, ale i operace částečně 32bitové). Navíc každá vektorová jednotka obsahovala i obvod umožňující provést součet všech osmi prvků vektorů. Celkový výpočetní výkon byl na dobu vzniku tohoto čipu úctyhodný – dosahoval až 500 000 000 operací typu multiply-and-accumulate za sekundu.
Reality Signal Processor je příkladem čipu, v němž se spojily vlastnosti RISCových procesorů s architekturou SIMD neboli Single Instruction Multiple Data. Jedná se o v současnosti značně populární architekturu, jejíž kořeny ovšem sahají hluboko do minulosti, konkrétně do šedesátých a sedmdesátých let minulého století (tato oblast výpočetní techniky je spojena se Symourem Crayem a jeho superpočítači). Do této kategorie patří ty architektury procesorů, u kterých se pomocí jedné instrukce může zpracovat větší množství dat. Například u rozšířené instrukční sady MMX je možné pomocí jediné instrukce provést součet dvou vektorů číselných hodnot. Může se jednat o osm osmibitových hodnot uložených v jednom vektoru, čtyři šestnáctibitové hodnoty v jednom vektoru atd. Této vlastnosti se dá v mnoha případech využít pro urychlení běhu programů, protože některé algoritmy (ve skutečnosti je těchto algoritmů možná až udivující počet) provádí velké množství stejných operací s rozsáhlým objemem dat – například se může jednat o aplikaci konvolučního filtru na rastrový obrázek, zpracování zvukového signálu, vynásobení matice vektorem, vynásobení dvou matic atd.
Obrázek 2: Schéma systému patřícího do kategorie SIMD.
Mezi přednosti čipů náležejících do kategorie SIMD patří jak relativně kompaktní instrukční sada, tak i paralelní a tím pádem i rychlý běh mnoha algoritmů, ovšem za cenu větších nároků kladených na programátora, popř. na překladač. Stále jen velmi malé množství programovacích jazyků totiž umožňuje explicitně vyjádřit vektorové či maticové operace (například u překladače Fortranu určeného pro superpočítače Cray bylo v manuálu explicitně řečeno, které jazykové konstrukce se budou skutečně provádět ve vektorové – SISD – jednotce). Z tohoto důvodu také není možné většinu SIMD konstrukcí zapsat v konvenčním vyšším programovacím jazyce: musí se použít buď hotová makra, ručně optimalizované knihovní funkce nebo specializované programovací jazyky. Určitou, ale nezanedbatelnou výjimku představují GPU na grafických akcelerátorech, které explicitně pracují s 2D a 3D vektory, přičemž programátor může předem zjistit, které operace budou skutečně provedeny paralelně.
Při programování modulu Reality Signal Processor měli vývojáři k dispozici dvě skupiny pracovních registrů. V první skupině se nacházelo třicet dva skalárních pracovních registrů, z nichž každý měl šířku 32 bitů. Tyto pracovní registry měly stejnou funkci, jakou jsme si popsali již v předchozí části tohoto seriálu – provádění běžných skalárních celočíselných aritmetických a logických operací, konverzi dat při jejich načítání a ukládání do paměti atd. Tato skupina registrů nás tedy dnes již nebude dále zajímat, ovšem o to zajímavější je druhá skupina pracovních registrů.
Ve druhé skupině se nacházelo taktéž třicet dva registrů, ovšem každý registr měl šířku plných 128 bitů. Těchto 128 bitů bylo interně rozděleno na osm částí, což znamenalo, že se vlastně jednalo o vektor s osmi prvky, přičemž každý prvek měl bitovou šířku šestnáct bitů. Každý prvek tohoto vektoru tedy mohl být samostatně zpracováván jinou vektorovou jednotkou, popř. se do vybraného registru mohlo uložit osm šestnáctibitových výsledků vypočtených paralelně ve všech osmi vektorových jednotkách. Některé instrukce navíc umožňovaly takzvané párování registrů, tj. provádění 32bitových operací. Mimochodem – datová paměť o kapacitě 4kB, o níž jsme se zmínili ve třetí kapitole, byla organizována po 128 bitových slovech, což znamenalo, že celý vektorový registr bylo možné z této paměti načíst či naopak uložit po přenosu jediného slova.
Většina „vektorových“ instrukcí podporovaných modulem Reality Signal Processor měla tři operandy, což znamená, že dva operandy byly zdrojové a třetí operand cílový. Navíc bylo možné u druhého operandu uvést takzvaný modifikátor, který určoval, se kterými prvky osmibitového vektoru bude operace prováděna. Uveďme si jednoduchý příklad s instrukcí typu vadd (vector add), tj. instrukcí pro součet dvou osmiprvkových vektorů. Jedná se o instrukci se třemi operandy (dva operandy zdrojové a jeden operand cílový), přičemž u druhého zdrojového operandu (zde konkrétně u vektorového registru v3) je uveden modifikátor:
| Instrukce | Operace se provede s prvky |
|---|---|
| vadd $v1, $v2, $v3 | 0 1 2 3 4 5 6 7 |
| vadd $v1, $v2, $v3[0] | 0 0 0 0 0 0 0 0 |
| vadd $v1, $v2, $v3[0q] | 0 1 2 3 0 1 2 3 |
| vadd $v1, $v2, $v3[1q] | 4 5 6 7 4 5 6 7 |
Z tohoto příkladu je patrné, že i takto jednoduchá instrukce může být překvapivě flexibilní.
V následující tabulce jsou vypsány základní aritmetické instrukce prováděné nad osmiprvkovými vektory:
| # | Instrukce | Význam |
|---|---|---|
| 1 | VADD | součet vektorů |
| 2 | VSUB | rozdíl vektorů |
| 3 | VSUT | opačný rozdíl vektorů (prohození operandů) |
| 4 | VABS | výpočet absolutní hodnoty prvků vektorů |
| 5 | VADDC | součet s přenosem |
| 6 | VSUBC | rozdíl s přenosem |
Vektorové jednotky však mohly provádět i různé logické a bitové operace, například:
| # | Instrukce | Význam |
|---|---|---|
| 1 | VLT | porovnání prvků vektorů (less than) |
| 2 | VEQ | porovnání prvků vektorů (equal) |
| 3 | VNE | porovnání prvků vektorů (not equal) |
| 4 | VGE | porovnání prvků vektorů (greater than or equal to) |
| 5 | VCR | jedničkový doplněk (negace) |
| 6 | VAND | operace typu AND prováděná nad prvky dvou vektorů |
| 7 | VNAND | operace typu NAND prováděná nad prvky dvou vektorů |
| 8 | VOR | operace typu OR prováděná nad prvky dvou vektorů |
| 9 | VNOR | operace typu NOR prováděná nad prvky dvou vektorů |
| 10 | VXOR | operace typu XOR prováděná nad prvky dvou vektorů |
| 11 | VNXOR | negace XOR prováděná nad prvky dvou vektorů |
Tyto instrukce mají velký význam například pro implementaci 2D grafických algoritmů (maskování spritu apod.).
Jednou z často prováděných operací při implementaci různých algoritmů z oblasti zpracování audio signálu či 2D grafiky, jsou operace typu multiply-and-accumulate, tj. součin následovaný přičtením výsledku součinu k mezivýsledku uloženého do akumulátoru. Modul Reality Signal Processor pro podporu provádění těchto operací obsahuje osm 32bitových akumulátorů, přičemž každý akumulátor je umístěn na výstupu ALU+shifteru každé vektorové jednotky. Instrukční sada RSP je rozšířena o několik instrukcí, které tento akumulátor využívají. Tyto instrukce jsou založeny na násobení dvou šestnáctibitových operandů, přičemž výsledek je 32bitový. Tento výsledek je buď přímo uložen do akumulátoru (tj. přepíše předchozí hodnotu), nebo je přičten k aktuální hodnotě akumulátoru. Povšimněte si, že se stále jedná o tříoperandové instrukce i toho, jakým způsobem je vypočten výsledek vrácený v cílovém operandu:
| # | Instrukce | Prováděná operace |
|---|---|---|
| 1 | VMUDL | acc = (src1 * src2) >> 16, dest = acc & 0×ffff |
| 2 | VMADL | acc += (src1 * src2) >> 16, dest = acc & 0×ffff |
| 3 | VMUDM | acc = (src1 * src2), dest = acc >> 16 |
| 4 | VMADM | acc += (src1 * src2), dest = acc >> 16 |
| 5 | VMUDN | acc = (src1 * src2), dest = acc & 0×ffff |
| 6 | VMADN | acc += (src1 * src2), dest = acc & 0×ffff |
| 7 | VMUDH | acc = (src1 * src2) >> 16, dest = acc >> 16 |
| 8 | VMADH | acc += (src1 * src2) >> 16, dest = acc >> 16 |
To, že je šířka akumulátoru 32 bitů, zatímco šířka všech operandů jen šestnáct bitů, není v oblasti zpracování signálu žádná novinka, protože v mnoha DSP je šířka akumulátoru větší než bitová šířka ostatních registrů i buněk operační paměti – například mnohé digitální signálové procesory určené pro práci s audio signálem zpracovávají sice šestnáctibitové vzorky, ovšem mezivýsledky jsou ukládány do akumulátoru o šířce 20 či 24 bitů.
Druhou modifikací sčítačky a násobičky v mnoha DSP je to, že pracují s takzvanou saturací. Její princip je velmi jednoduchý – výsledky aritmetických operací nepřetíkají (nepočítá se tedy „modulo N“), ale v případě, že je výsledek operace větší než nejvyšší reprezentovatelná hodnota, zapíše se do výstupního registru maximální hodnota, například 65535 u DSP pracujícího s šestnáctibitovými čísly bez znaménka (to je přesně případ RSP). Podobně je tomu u minimálních hodnot, pokud jsou vzorky reprezentovány čísly se znaménkem. Kvůli saturaci sice taktéž dochází ke ztrátě informace – například ořezání maximálních hodnot u audio signálu – jedná se ovšem o mnohem menší zlo, než kdyby došlo k přetečení a uložení pouze spodních bitů výsledku se zanedbáním bitů s nejvyššími váhami.
Druhou jednotkou umístěnou na čipu Reality Co-Processor je modul RDP neboli plným jménem Reality Display Processor. Jedná se o konfigurovatelnou rasterizační a texturovací jednotku řízenou příkazy posílanými z modulu RSP popsaného výše (viz též schéma zobrazené pod tímto odstavcem). To znamená, že při správném naprogramování RSP bylo zajištěno plně automatické vykreslování 2D či 3D scén, a to bez nutnosti toho, aby do tohoto procesu jakkoli zasahoval hlavní mikroprocesor. Reality Display Processor byl navíc vybaven i lokální pamětí o kapacitě čtyři kilobajty, která byla použita pro uložení právě využívané textury. Textury mohly být uloženy v několika různých formátech, od běžného 16bitového či 24bitového RGBA přes osmibitový formát s paletou až po formát, v němž byla textura reprezentována texely se specifikací světlosti, popř. světlosti a průhlednosti (použití různých formátů bylo vynuceno mj. i relativně malou kapacitou paměti pro textury, o níž jsme se zmínili výše).
Obrázek 3: Reality Display Processor je řízen příkazy posílanými z Reality Signal Processoru.
Reality Display Processor se od některých dalších dobových 3D akcelerátorů odlišoval především tím, že byl široce konfigurovatelný, což znamenalo, že programátoři mohli (samozřejmě opět přes RSP) implementovat celou řadu různých grafických algoritmů, včetně Gouraudova stínování, využití paměti hloubky (Z-bufferu), environment mappingu, bilineární či dokonce trilineární interpolace při texturování popř. provádění antialiasingu při vykreslování hran. Zejména díky trilineární interpolaci a antialiasingu byly 3D scény vykreslované herní konzolí Nintendo 64 většinou kvalitnější v porovnání s konkurenčními konzolemi, a to přesto, že velikost (rozlišení) textur byla omezena relativně malou kapacitou texturovací paměti (navíc se při použití trilineární interpolace musela textura ukládat vícekrát, například s rozlišením 32×32 pixelů, 16×16 pixelů a 8×8 pixelů). Při texturování bylo též možné provádět perspektivní korekci na úrovni jednotlivých pixelů, použít framebuffer (do něhož se vykreslování provádělo) jako zdroj pro další texturu (efekty zrcadlení) apod.
Do rasterizační jednotky byly z Reality Signal Processoru postupně posílány příkazy, které jednotka ihned začala vykonávat. Většina příkazů měla délku 64 bitů a lze je rozdělit do třech kategorií: konfigurační příkazy, řízení rasterizační a texturovací pipeline a vykreslovací příkazy. Nejkomplexnější byly konfigurační příkazy sloužící pro nastavení či přenastavení RDP. Mohl se například přesně specifikovat formát výstupu/framebufferu (RGBA, YUV, intenzita, intenzita+průhlednost), formát pixelů ve framebuferu (4bit, 8bit, 16/32bit RGBA), šířka framebufferu, adresa framebufferu (šla snadno změnit), adresa Z bufferu atd. U textur bylo taktéž možné přesně specifikovat jejich formát.
Obrázek 4: Do RDP vstupují údaje o trojúhelnících/obdélnících i o texturách, celá vykreslovací pipeline je konfigurovatelná.
Nejzajímavější jsou konfigurační příkazy určené pro řízení vykreslování: zde bylo možné nastavit ořezávací box (scissor test), povolit interpolaci textur (včetně typu interpolace), povolit perspektivní korekci při mapování textur, zapnout dithering (v závislosti na formátu framebufferu), měnit stav Z bufferu (zákaz zápisu, zákaz aplikace testu na hloubku fragmentů) apod.
Vykreslovací příkazy byly poněkud překvapivě (zejména při porovnání s příkazy, které jsme si uvedli u dalších herních konzolí) velmi jednoduché. Jednalo se o příkaz pro vykreslení vyplněného čtyřúhelníku a o příkaz pro vykreslení čtyřúhelníku pokrytého texturou. Jak budou tyto čtyřúhelníky vytvořeny bylo ponecháno na programovatelném modulu RSP, který většinou ve svých vektorových jednotkách prováděl jak výpočty projekce, tak i výpočty související s osvětlovacím modelem. Do poslední skupiny příkazů patří příkazy pro řízení vykreslovací pipeline. Většinou se používal příkaz pro synchronizaci pipeline ve chvíli, kdy došlo ke změně textury.
Z tohoto popisu je zřejmé, že díky kombinaci RSP s RDP byl grafický subsystém herní konzole Nintendo 64 velmi flexibilní, ovšem v některých případech se negativně projevovalo omezení rozlišení textur kvůli poměrně malé kapacitě vyrovnávací paměti pro textury. K tomuto tématu se vrátíme při popisu a porovnání her vytvořených pro jednotlivé herní konzole páté generace.
