Diit.cz - Novinky a informace o hardware, software a internetu

Správa dat a výpočetních vláken, rasterizace

Intel čtyřjádro
Po mnoha a mnoha měsících spekulací a nepotvrzených informací konečně sama společnost Intel poodhalila roušku tajemství kolem projektu Larrabee, od kterého si ona i IT svět jako takový, slibuje poměrně hodně. Co je tedy Larrabee zač, co od něho můžeme očekávat a jaké to za rok-dva po jeho uvedení na trh bude?

Kapitoly článků

I v oblasti thread managementu na to jde Larrabee odlišně od klasických GPU. Silou svých výpočetních jednotek si poradí jen s něčím (zde primárně s vektory). Primitiva a pixelová data spolu se souvisejícími shaderovými programy jsou spravována softwarově. Jaká je však podobnost s AMD/nVidia, to těžko říci, takto jemné nuance architektur svých GPU si výrobci nechávají samozřejmě jen pro sebe.

Každé jádro v čipu Larrabee se, jak jsme již uvedli, umí chovat jako čtyři, tedy umí počítat čtyři softwarová výpočetní vlákna najednou. Svým způsobem tak obchází místa, kde by mohlo docházet v procesech výpočtů v neúměrně vysokým latencím, tato čtyři výpočetní vlákna sdílejí společné zdroje (neboť fyzicky jde o jedno jádro, pouze v logické úrovni umí zpracovávat čtyři naráz).

Architektura Intel Larrabee: thready

Larrabee k renderingu přistupuje takto: výpočetní thread má na starosti správu zdrojů pro větší skupinu instrukcí a dat (tomu v Intelu říkají „fiber“). Normálně thread spravuje osm „fiberů“ (hergot to je ale odporné slovo, vrátíme se raději k českému „vláken“ :-). Hardwarový thread (zde zůstaneme pro odlišení u anglického) spravuje obsah tak, aby byl k dispozici pro ono vlákno. Úkolem vlákna pak je spravovat spouštění paralelních datových úloh na skupinách po šestnácti „strands“ („prameny“, ale už v té terminologii začíná být chaos ;-), neboť, připomeňme si, vektorové jednotky jsou uspořádány po šestnácti. Právě „strand“ je tím, co u běžného grafického hardware nazýváme taktéž vláknem. Legrace je v tom, že Intel Larrabee nevykonává žádná hardwarová výpočetní vlákna skrze pevněji danou výpočetní/shaderovou architekturu, ale vše „emuluje“ pomocí software, jak jsme si psali výše.

Podívejme se hlouběji. Se čtyřmi softwarovými thready na každé jádro (těch bude připomeňme nejspíše něco mezi 8 až 32), osmi vlákny na thread a násobkem šestnácti pramenů na každé vlákno se dostáváme k obrovskému číslu paralelně vykonávaných pramenů. A protože je Larrabee v principu klasický procesor, všechny tyto výpočetní cestičky jsou k dispozici současně pro masivně paralelní aplikace, ale narozdíl od CPU se zde o jejich správu nestará operační systém, nýbrž s nejvyšší pravděpodobností ovladač Larrabee jako takový.

Intel si ale bude muset dát velký pozor na režii takového řešení. Architektura je sice velmi dobře připravena, ale při správě takto gigantického množství dílčích výpočetních vláken je třeba udržovat mnoho a mnoho aktivních dat pro rychlé přehazování výpočetním jednotkám, aby se tak co nejvíce omezily latence, které dokáží principielně srazit jakkoli výkonný systém na kolena, pokud s tím návrh architektury nepočítá (i proto tak moc cache pamětí).

Optimalizovaná rasterizace

Jak to tedy Larrabe provádí s klasickou metodou renderingu používanou v DirectX, tedy rasterizací? Již jsme zmínili, že Larrabee půjde na rasterizaci nikoli hrubou silou, ale chytrostí vynikající metody tile-based renderingu, se kterou přišla známá společnost STMicro u legendární karty Kyro II (které myslím zlomil vaz fakt, že si nerozuměla s Morrowindem, škoda jí, tile-based/HSR alias Hidden Surface Removal je fajn věc, která dokázala přinést až nečekaně vysoký výkon při „podezřele podřadných“ parametrech grafického čipu (tehdy se tomu ještě neříkalo GPU)).

Architektura Intel Larrabee: paměťová náročnost

Díky tile-based renderingu si, opět se posuňme do roviny teoretických úvah, může Larrabee vystačit s minimálním množství grafické paměti a šířky externí paměťové sběrnice, což může vyústit ve viditelné snížení výrobních nákladů oproti konvenčnímu robustnímu řešení. Vývojáři samozřejmě budou mít k dispozici již mnohokrát zmíněný softwarový renderer, nebudou muset psát věci „from scratch“ (přestože tato možnost tu bude). Prozatím ještě není rozhodnuto, zdali bude renderer k dispozici pouze jako uzavřená binárka, nebo jej Intel pustí ven formou komukoli dostupného zdrojového kódu, ale jistě mluvím za všechny „linuxáky“, když si dovolím doufat, že v duchu tradice podpory otevřených standardů a opensource komunity se Intel ve finále rozhodne pro druhou možnost.

Tile-based rendering pak zjednodušeně spočívá v rozdělení scény na menší oblasti (tile), které se průběžně prohánějí skrze menší renderovací pipeline a výsledek opět skládá do celku. Jednotlivé dílčí oblasti jsou přitom nejprve spočítány a vyhodnoceny jako viditelné a teprve výsledek tohoto „předvýpočtu“ je předhozen v podobě celé scény stream processing jednotkám na výpočetně nejnáročnější dokončení scény, shaderové výpočty (v DirectX 10+ to může být trochu komplikovanější, ale principielně to takto je). Intel navíc provádí Z-culling (alias vyhození bodů, které jsou ve scéně schovány za jinými a tudíž nejsou vidět a je tak zbytečné je renderovat) během geometry, fragment i pixel výpočtů, což přispívá k dalšímu navýšení optimalizace renderování scény.

Variace na tuto metodu nalezneme jak v čipech PowerVR a konzoli Sega Dreamcast, tak i třeba v GPU Xboxu 360, které využívá malou, ale extrémně rychlou 10MB embedded paměť. Samotný Microsoft tuto metodu zkoumal v polovině devadesátých let v rámci projektu Talisman, ale ve výsledku nic nevzniklo. Pokud vás metoda zajímá více, zavítejte třeba ke kolegům na Beyond3D, kteří ji věnovali před sedmi lety (to to letí) samostatný článek.

Naproti tomu stávající GPU ATI a nVidia jdoucí cestou „hrubé síly“ (a jak víme, hrubá síla je zpravidla velmi účinná, zejména pak u dnešních GPU, která sama o sobě také mají spousty všemožných optimalizací) immediate mode renderingu, který vyžaduje podsatně více paměti, paměťové propustnosti, neboť modelově zpracovává každý fragment renderované scény. GPU samozřejmě obsahují řadu technik, jak toto ošetřit (ne nepodobných HSR), ale i tak dochází k situacím, že výpočetními jednotkami projde něco, co se ve výsledku nezobrazí. Ale ono je toto vyhazování neviditelných pixelů ošemetná věc, HSR se musí implementovat velice čistě a precizně, nelze na scénu „bezhlavě vlítnout“ a vyházet hromadu věcí, aby pak ve výsledku byly vidět chyby v renderingu.

Larrabee tedy jde jiným směrem. Zatímco stávající konzervativní GPU mají hromady speciálně navržených jednotek pro geometrii, rasterizaci, texturování, filtrování kompresní/dekompresní techniky a mnohé další, Larrabee nese pouze elementární potřebnou pevně definovanou logiku primárně pro texturování a zbytek řeší univerzálními výpočetními jednotkami ve spojení s obslužnou softwarovou vrstvou. Ve výsledku tak sice může v jistých místech riskovat pomalejší práci oproti optimalizovanému hardware, ale o to více flexibilní je, když dojde na unikátní potřeby desítek či stovek různých her a aplikací.

Tak trochu to lze principielně přirovnat ke grafikám generace DirectX 9 a starším, které měly pevné počty pixel a vertex shaderů a jak byl nastaven jejich poměr při návrhu GPU, tak to prostě bylo dáno. DirectX 10 grafiky přišly s unifikovanými shadery a od té chvíle mohou poskytovat (~)100 % výkonu bez ohledu na to, zdali hra zrovna potřebuje více vertex nebo pixel výpočtů.

Larrabee je tak díky návrhu architektury více univerzální. Ale to hovoříme v rovině relativního srovnání architektur, jakmile bychom se měli bavit o absolutním výkonu, nemůžeme v tuto chvíli posloužit žádnými srovnávacími testy. Na to je prostě příliš brzy.

Kapitoly článků

David "David Ježek" Ježek

Bývalý zdejší redaktor (2005-2017), nyní diskusní rejpal.

více článků, blogů a informací o autorovi

Diskuse ke článku Architektura Intel Larrabee

Čtvrtek, 14 Srpen 2008 - 14:52 | Ren1 | ...
Čtvrtek, 14 Srpen 2008 - 14:39 | Anonym | Proc myslis, ze si myslim, ze me kazdy chce...
Čtvrtek, 14 Srpen 2008 - 13:59 | Ren1 | weepy> Ale no tak..:-( Myslis, ze bys...
Středa, 13 Srpen 2008 - 19:10 | Anonym | Ren: Prostredky, kterych pouzivas, se nelisi od...
Středa, 13 Srpen 2008 - 13:19 | Ren1 | weepy> Hehe, zase ta neurcita cestina...
Středa, 13 Srpen 2008 - 13:17 | Ren1 | weepy> Tak pocitam, ze uz bylo po debate,...
Středa, 13 Srpen 2008 - 11:06 | Anonym | Vsimas si, ze ses timto vlozil sam do diskuse,...
Středa, 13 Srpen 2008 - 09:51 | Ren1 | weepy> Urcite nic, co bys sam davno...
Úterý, 12 Srpen 2008 - 14:58 | Anonym | Ren: no tak flame uz je sociologicky prostudovany...
Úterý, 12 Srpen 2008 - 14:44 | Ren1 | weepy, Milan M> Panove, vasi debatu jsem...

Zobrazit diskusi