Reklama

Larrabee, revoluční GPU od Intelu

V roce 2009 přijde Intel na trh se svými samostatnými grafickými akcelerátory, které zatím nesou kódové označení Larrabee. Největší výrobce procesorů již nyní prozradil mnoho střípků o architektuře a technologiích své chystané zbraně. Larrabee jde jinou cestou než současné grafické čipy ATI a nVidia.

Intel – staronový hráč na poli grafické akcelerace

Intel a grafické akcelerátory, to je velmi zajímavá kapitola. Po neúspěchu s kartami Intel 740 společnost tento trh opustila, ale vlastně neopustila, protože se stáhla do segmentu integrovaných grafických jader. Ačkoliv jen málokdo by o Graphics Media Acceleratoru uvažoval jakožto o řešení pro hry, v hrubých číslech je Intel se svými IGP největším dodavatelem grafických adaptérů (i když nVidia tvrdí, že přes 70 milionů jich je „mrtvých“, a tak je jedničkou ona).

Přesto je však Larrabee z velké části výlet do neprobádaných končin. A to nejen z toho důvodu, že prosazení samostatného grafického akcelerátoru vyžaduje daleko vypilovanější ovladače, spolupráci s herními vývojáři a marketing, než to, co Intel zatím předvádí u svých integrovaných GMA. Druhým důvodem je architektura Larrabee, která má s dnešními IGP pramálo společného.

Intel vyvíjí Larrabee už poměrně dlouho – během té doby postupně zveřejňuje informace a přísliby, na což nVidia s oblibou reaguje tak, že Larrabee je snímek z prezentace, a proto nemá důvod se jej bát. Mají se Kaliforňané obávat, nebo ne? Na jednoznačnou odpověď je ještě příliš brzy, ale snad budete po přelouskání článku o něco moudřejší. Intel byl poměrně sdílný, pamatujte ale, že mnoho dílků do skládačky ještě chybí. Některé se dozvíme už 12. srpna na konferenci SIGGRAPH 2008.

CPU, nebo GPU?

Intel si sám je dobře vědom toho, že snažit se o výkonné grafické jádro by pro něj bylo bruslení po tenkém ledu. Proto u Larrabee využil svých zkušeností z toho, co umí nejlépe. Larrabee má tedy narozdíl od klasických GPU velmi blízko k mnohojádrovému procesoru. Jelikož výpočetní jednotky staví na architektuře x86, bude na Larrabee možno provozovat softwarové renderovací enginy. Zároveň ale čip podporuje Direct3D a OpenGL.

Intel si zavčasu všiml, že shadery grafických čipů dosahují při schůdných výrobních nákladech daleko lepšího teoretického výkonu, než jaký je schopen poskytnout obyčejný dvou- nebo čtyřjádrový procesor. A také, že od vysoce specializovaných jednotek se vývoj ubírá k unifikaci a univerzálnějším „stream procesorům“. A zatímco ATI a nVidia postupně vytváří ze specializovaných čipů univerzální, Intel se rozhodl jít opačnou cestou a vyjít z vysoce univerzálního základu mnohojádrového x86 procesoru.

Extra edice Zoner Photo Studio
Reklama

Paralelizace se tedy stala základní ideou Larrabee. Je však velmi těžké využít potenciál grafického jádra pro jiné výpočty, i když jejich hrubá síla dokáže často divy i s nepříliš dobře optimalizovanou aplikací. Tento problém chce Intel alespoň částečně ošetřit právě tím, že jednotky Larrabee zvládají instrukční sadu x86.

Průměrně: 4.5 (17× hodnoceno)

Komentáře

Me to nevychazi. :-(

... lze snadno spočítat, že blok 64 × 64 pixelů, každý s 32bitovou informací o barvě, zabírá přesně 128 kilobajtů.

64*64*4= 16384 B (32bitu = 4byte)

Dopl. Asi chyba pri inspiraci. V originalnim clanku plati kalkulace 128x128x8 = 128kB (32bit color, 32bit Z-buffer).

Re: Me to nevychazi. :-(

 Máš pravdu, neuvědomil jsem si, že jsou to bity a ne bajty...

Hezky clanek... i kdyz jsem

Hezky clanek... i kdyz jsem byl casto uplne mimo :( ... hezke je a myslim ze to bude i velmi dobre to ze Larrabee by melo predem pripravovat data pro CPU.. to bych rekl ze je dobra vec... pac CPU se porad a porad jenom flaka...lemra lina :D

Re: Hezky clanek... i kdyz jsem

a kdyz ma pocitat slozitou fyziku, tak zas nestiha...

Urceni supercomputing

Nevim jaka je vykonnost (v GFLOPS) na 1GHz taktu u x86 jednotek v Larrabbe a jaka je jejich predpokladana frekvence. Ale touto architekturou by mohli odrazit pokusy o nastup cistych GPU pripadne multi-core(Cell) do supercomputingu. Uz schopnost provozovat vicevlaknove aplikace na bazi x86(univerzalni CPU) s vektorovymi jednotkami jako bonusem by mohlo byt budoucna v oblasti supercomputingu zajimavou alternativou.

rendering

takže.... jestli tomu správně rozumím, tak funkčnost ve hrách je ve hvězdách, ale každopádně to bude absolutní senzace pro lidi, co potřebují renderovat (artlantis, 3Dmax, cinema)?

Re: rendering

A přesně tohle mně zajímá. Kdyby na tom šel pustit unbiased rendering, což by dle zmíněné podpory x86 instrukční sady jít mělo, tak by to mohla být supr věc. I hry se začínají směrovat k raytracingu. Pak dle počtu jader(uváděno minimálně 8) by i ta spotřeba 300W byla rozumná. Zatím to vypadá slibně. Jen jak na tom bude s tím výkonem oproti klasickým CPU..

Re: rendering

necháme se překvapit, osobně tipuji, že právě v těchto úlohách bude mnohem ( >2x ) výkonnější než cpu. Jinak by larrabee asi nemělo smysl a intel by jen vydával místo quad okta a více jádrové procesory. A nebo bude přibližně stejně výkonné, ale jader bude mnohem víc... težko říct. Uvidíme

Dynamic branching - VPU

Dynamic branching - VPU pracuje pri jednom pruchodu s max. 16 pixely, v ramci 16 pixelu pomuze mask register

Ring-bus a paměťový řadič - jeden ring-bus obslouzi max. 16 jader, pak se prida dalsi (propojeny) ring(y). Pokud budou 2 64bit pametove radice na ring, tak pruchodnost pameti muze skalovat s poctem jader.

Cache Coherency mezi chipy ma Intel zmaknutou s CSI (QPI), u Larrabee PCB byly videt 2 konektory oznacene BSI, pravdepodobne nazev pro odrudu CSI (B jako Basic?)
http://www.tgdaily.com/images/stories/article_images/intel_roadmap/larra...
http://www.tgdaily.com/images/stories/article_images/intel_roadmap/larra...

pro zajemce link na jednu ze SIGGRAPH prezentaci http://softwarecommunity.intel.com/UserFiles/en-us/File/larrabee_manycor...

Larrabee

Nejzajímavější na celém projektu je, že zatím nikdo nemá sebemenší tušení, kam se to výkonnostně postaví. Univerzálnost a široká programovatelnost je moc hezká, ale v dnešní době v grafickém trhu stačí jedna(!) chyba a z výborného řešení se stane propadák (např. MSAA resolve na R600).

Zkušenosti Intelu s CPU jsou obrovské, ale s GPU opravdu minimální. Od doby i740 se pokoušel o několik projektů, několikrát nabral volné inženýry ze starých grafických společností, ale vždy se skončilo ještě dřív, než šel čip do výroby a inženýry opět propustil. Na Beyond3D fóru dokonce kdosi počítal, na jakém frame-rate by na 1GHz Larrabee běžely některé hry, kdyby vycházel pouze z čistého aritmetického výkonu potřebného pro p/v/g shading (tedy bez jakýchkoli dalších limitů) a i kdyby se ten výsledek vynásobil dvěma (finální verze má mít 2GHz), stále to nebylo více, než u současných grafických karet.

Otázka je tedy, kam Intel s Larrabee přesně míří, protože pokud má jít primárně o grafický čip, tak to možná nebude až taková výhra, protože v současné době (a během 1 roku se to rozhodně nezmění) bude v naprosté většině ohledů specializovaná architektura lepší (efektivnější), než univerzální. Pokud chce Intel s Larrabee nahradit jak GPU, tak CPU a v systému jich bude více, pak bude systém brutálně limitovaný rychlostí zpracování sériového kódu. Na tenhle problém narazili narazili vývojáři F@H ve Stanfordu. F@H funguje mohutně paralelně, ale vzhledem k tomu, že se počet aritmeticko-logických jednotek v GPU zvyšuje mnohonásobně rychleji, než sériový výkon CPU, zjistili, že při překročení cca 300 ALUs v GPU už je brzdou kód, který není možné paralelizovat a který běží na jednom jádru CPU. Takže bez navýšení výkonu na 1 jádro CPU (či bez dalších optimalizací) není možné využít další ALUs v GPU, protože je CPU "nenakrmí"...

Re: Larrabee

Vidim to pri spusteni klienta F@H na HD4870. Uz pri HD3870 nebyl schopen quad@3,2 nakrmit GPU praci na zatez vice jak 80%. U Larrabbe diky vice x86 jadrum by "drabu" mohlo byt dost.

Re: Larrabee

Nejde o počet jader. Sériový kód běží na jednom jádru, takže ať máme single-core na 2GHz, nebo quad-core na 2GHz, běží stále stejně rychle. Stanford zmiňoval, že řešením by bylo, pokud by na každém jádru CPU běžel jiný oddělený výpočet a každé jádro by mělo přiřazené vlastní ALUs grafické karty, což by využilo více z potenciálu procesoru i GPU, jenže by to nijak nezkrátilo dobu potřebnou pro výpočet, jen by se za stejný čas provedlo dvojnásob výpočtů. Může se zdát, že je jedno, jestli jeden výpočet provádím hodinu a druhý taky hodinu, nebo jestli za dvě hodiny budou najendou dokončené dva, ale problém je v tom, že výpočty F@H jsou časově náročné a pokud není výpočet dokoknčen a uživatel vypne PC (nebo F@H), tak je všechen výpočetní výkon u nedokončeného výpočtu ztracen, zatímco pokud by byl výpočet proveden v polovině času, byla by vyšší pravděpodobnost, že by se alespoň část výpočtů stihla za danou dobu dokončit.

Re: Larrabee

Tak to mají naprogramovat tak, aby to pravidelně ukládalo progress, nebo aby to automaticky uložilo při ukončení aplikace, a takhle blbě se nevymlouvat. 

Re: Larrabee

Osobně mi běžný gracifký klient Fah na 3870 a ukládá si v nastavených intervalech (3-30 minut myslím - co si kdo vybere, osobně mám 4 minuty) už vypočtená data do souborů. Když na 52% procentech vypnu (i zasekne se počítač), tak po opětovném spuštění se vypíše hláška "will resume from checkpoint file" a začne na těch 52% pokračovat. Ten klient to umí průběžně ukládat.

Re: Larrabee

Tak kde je problém? 

Re: Larrabee

Podle mne je problem v pomeru rezie vypoctu (provadena CPU) a vlastnimi vypocty (via GPU). Nebo je problem v typu soucasnych uloh (jejich algoritmizaci), ktere dnes z vetsiho poctu SP nejsou schopny profitovat. Co jsem sledoval prispevky od VP ve foru F@H tak bylo receno, ze pri reseni slozitejsich molekul dojde k uspesnejsimu vytizeni vetsiho poctu SP a tim i k dosazeni celkoveho vyssiho vykonu.

Re: Larrabee

Ano, tak nějak to je dle mne též. Při počátečním uvedení prvních WU, těch testovacích zda klient běhá správně (pro public betu - měli 5000 těch částí či jak to nazvat, ty současné mají o hodně více), tak ty WU nevytížili 3870 ani třeba z 50%...poté uvolnili větší WU asi i náročnější a šup hned se mohlo zatížení vyhoupnout na 70 a více %. Tedy co sem pochopil, tak když SP počítají WU, tak jakoby jeden SP je jako jedna výpočetní jednotka - tedy když jsou WU a počítané výpočty jednodušší = nižší vytížení a část GPU se fláká. Když jde o složitější větší a náročnější = větší vytížení a všechny SP jedou naplno. Ale jeden z hlavních problémů, jak říká lazar, bude asi právě v režii cpu. Protože sem si všiml, klient vytěžuje 50% CPU, neboli u X2 je to jedno jádro. Tedy úvaha myslím už zazněla, pokud se docílí toho, že GPU klienta bude moci krmit více jader najednou..... výsledek je jasný. Osobně je gpu krmeno u mne Athlonem X2 zhruba na 2.5 GHz a mám určitou hodnotu PPD (points per day, ohodnocení jak rychle dodává výsledky a počítá) a vytížení. Ti kteří mají výkonnější procesor (kupříkladu intel na víc jak 3GHz) budou mít více PPD (tedy vlastně rychlejší výpočty). To se dá uvažovat tedy dokud je GPU nevytíženo na 100%. Jakmile se GPU vytíží na 100% - lepší procesor nepomůže.
Tohle je velmi neumělé popsání a částečně asi nepřesné či chybné, nemohu říci zda jsem to pochopil správně. Doporučuji si prostudovat Fah forum a Fah wiki, vše je zde dobře vysvětleno (vysvětleno ohledně bodů, rychlosti počítání, omezení procesoru, sou tu třeba i tabulky které procesory či gpu počítají jak rychle a podobně).
Zahlédl jsem i popisy kdy běžely 2x 3870 (ne v crossfire) a každou krmilo jedno jádro intel quad. Zbylá dvě jádra procesoru počítala přes obyčejné klienty pro cpu. Tedy celkově 2x GPU klient a 2x CPU klient. Tam už to bylo něčem jiném.

Re: Larrabee

Pokud pustim F@H proti Crossfire s jednim GPU2 klientem je jedno GPU zatizeno cca z 60% a druhe 20%. Celkova rychlost vypoctu (PPD) se nezvysi (tento rezim nakonec neni ani doporucovan). Jediny smysl ma snad s ohledem pouze k distribuci tepelne zateze (u dvou karet). Jiny postup je disable CF a pripojeni druhe karty k monitoru (aby byla aktivni), pak je mozne spustit nezavisle dva GPU2 klienty, kazdy proti jinemu GPU. Samozrejme zatez CPU je potom enormni.

Re: Larrabee

Tak tak, nezkoušel sem CF ale dává to smysl, asi si systém myslí, že po zapnutí CF je to jedno GPU. Tedy rozdělí se zátěž a teplota. Ano a dva GPU klienty už, jaksi robí jinou zátěž.

Re: Larrabee

>Tak kde je problém?
nejsou lidi ;)
kazdou chvili vychazi novy HW s odlisnym vykonem, architekturou i schopnostmi
navic kazdy vyrobce (ATI, nVidia, IBM, Intel) pouziva vlastni ISA a programove rozhrani
az bude jednotny standart (OpenCL nebo neco jineho) tak bude realne programovat SW, ktery zpusob vykonavani prizpusobi dostupnemu HW
kazda WU pak muze specifikovat pozadavky na vypocetni vykon (FLOPS), operacni pamet (working set size) a schopnosti HW (napr. SP FP vs DP FP)
F@H client ktery najde C2Q, RV670 a RV770 si pak muze rici o par komplexnich a hodne jednoduchych WU
komplexnim WU se prideli volna jadra CPU, jednoduche WU se budou posilat po dvou na RV670 a po peti na RV770

Re: Larrabee

Tak to mam asi zkusenost s jinym F@H. Vypocet jedne WU na GPU mi trva cca 90minut a kazdou minutu to ulozi stav. V pripade preruseni to pokracuje v krasojizde na %WU kde to skoncilo.

Re: Larrabee

u F@H neni problem "kód, který není možné paralelizovat", ale kod, ktery nebyl paralelizovan
viz http://folding.stanford.edu/English/FAQ-ATI2 "For now, the GPU2 core uses the CPU a bit in addition to heavy use of the GPU. However, we hope to off load the calculation completely to the GPU in the future."

zajimave to intel pojal

Ac to na prvni pohled nevypada zle, tak se pro srovnatelny vykon s dnesnimi GPU obavam ohromne vetsi vypocetni narocnosti, - moc kremiku , moc proudu, moc tepla. Zatim me to spis prijde vyuzitelny do grafickych stanic pro urcity softwary nez do hernich PC.