Intel Larrabee

[animaN]

Mozda ce imati i toliko, zaista ni ja ne znam, sve je jos u domenu spekulacija. Medjutim, Larrabee ako ne uspe kao GPU uspece kao CPU -- jednostavno ne moze da ne uspe.

Realno, Intel svom snagom stoji iza tog projekta, pa verujem da se nece obrukati, shtavishe

Sto se tice Software-optimizacije , to nije trend Dusane u modernom software developmentu se sve svodi na lakse , jednostavnije i brze .... brze u smislu (vremenske realizacije).
Konkurencija na trzistu je velika , jedan developer iz nase firme kad ga pozajmimo nekoj drugoj kompaniji na dan kosta 1200€
Niko ne haje ako projekat od 500.000 do milion kodnih linija u nekom aspektu nije maksimalno optimizovan. Ovdje ne pricam o homemade namenama kodiranih preko vikenda gdje covek moze bez kriticnih faktora kao sto je vreme do mile volje detaljno da ulazi u zadnji bit izvrsnog koda .

Kad projekat treba materialno da donese dobit tvom nalogodavcu a svaki izgubljeni dan ga kosta na desetine hiljada evra veruj mi zadnje nasto misli je optimizacija source code'a. Osnovna funkcionalnost mu je prvenstveno najbitnija.

Takav je realitet koji dozivljavam svaki dan ..... Nisu danasnji software developeri lenji za bilo kakvu optimizaciju nego ih trziste tera da se koncentrisu na zadatak i resenje postavljenog problema na najlaksi i najbrzi nacin sto
se slazem nije uvek performanski gledano najefikasnije ali who cares ako zadatak nije performanski kritican a ispostovace definisani rok.

Nisam ja ni mislio da je bilo ko lenj, naprotiv, samo mislim da se HW pojavljuje previshe brzo, a da se sve grana na previshe, kako bi ja to nazvao, podstandarda, shto SW inzenjerima ne ostavlja puno mesta za kreativnost i vrhunsku optimizaciju, vec se sve vodi na to ko ce prvi da izbaci reshenje i u koliko primeraka ce da ga proda..

Prosto mi je tuzna ova trenutna istina koju si izneo:

Naravno da ce postojati segmenti gdje ce realna brzina izvrsavana i optimizacija imati svoj znacaj. Samo ce to u buducnosti imati sve manje i manje znacaja i biti kompenzirano brahialnom racunarskom snagom samog HW'a sto je donekle i danas vec slucaj.

Cenim da projekti AMD-a i Intel-a u objedinjenja CPU-a i GPU-a mogu dosta toga promeniti u samoj filozofiji finalnog korisnika

 

[SORD]

Realno, Intel svom snagom stoji iza tog projekta, pa verujem da se nece obrukati, shtavishe



Nisam ja ni mislio da je bilo ko lenj, naprotiv, samo mislim da se HW pojavljuje previshe brzo, a da se sve grana na previshe, kako bi ja to nazvao, podstandarda, shto SW inzenjerima ne ostavlja puno mesta za kreativnost i vrhunsku optimizaciju, vec se sve vodi na to ko ce prvi da izbaci reshenje i u koliko primeraka ce da ga proda..

Prosto mi je tuzna ova trenutna istina koju si izneo:



Cenim da projekti AMD-a i Intel-a u objedinjenja CPU-a i GPU-a mogu dosta toga promeniti u samoj filozofiji finalnog korisnika

Objedinjavanje cpu i gpu je trend koji ide uzlaznom putanjom sto se da videti i iz napora koje nvidia ulaze u pravljenje svog x86 cpu-a.

 

[audiofreak]

Posto nemamo za sada sobu za developere i programiranje stavicu ovo ovde.

Dakle, programeri medju nama (a i oni radoznali kojima su hardver i masinske instrukcije zanimljivi) pogledajte C++ Larrabee Prototype Library.

Kao sto rekoh, Intel je vrlo uporan u tome da pruzi sjajnu podrsku za programere za svoju novu platformu.

 

[thecookiemonster]

Ne treba zaboraviti ni da je Larrabee 64-bitni "GPU" (NVIDIA i AMD su 32-bitni i mogu da adresiraju max 4 GB RAM-a koliko ja znam).

Mislim da nije toliko razlika u kolicini RAM-a, koliko u nacinu pristupa.
Larrabee donosi CPU-like adresiranje sto programeru daje veliku fleksibilnost. S druge strane, GPU-ovi su ceo svoj memorijski model gradili za potrebe grafike u skladu sa specificnim API-om, jer drugaciji pristup memoriji zaista nije bio potreban. Sad za GPGPU potrebe teze da se oslobode vecine restrikcija, ali moraju da vuku malo starog balasta: sve pozive memoriji upucuje teksturna jedinica (TMU) iako sam trazeni podatak nije tekstura.

Ovaj princip se uglavno odnosi i na aritmetiku. GPU-ovi idu od specjalnih jedinica ka sve generalnijim, a Larrabee suprotno: od generalnog procesora kome se dodaju specijalizovane jedinice.
Ima i Larrabee svog balasta: x86 kompatibilnost vuce sve od 16-bitne ere, sto deluje prilicno pointless.

Ja sam pogledao nove instrukcije i prijatno sam iznenadjen da su napokon dodate instrukcije gather i scatter -- nesto sto sam i sam odavno trazio Intelu da ubaci u procesore jer bi mi dobro dosle za 3D rekonstrukciju.
Prva implementacija ovih instrukcija sigurno nece biti spektakularna jer ce gather i scatter biti sastavljene od nekoliko instrukcija interno (u najgoroj varijanti 16 taktova), ali sledeca verzija cipa ce ih verovatno imati odradjene skroz u hardveru.

Ne mogu puno da urade povodom ubrzavanja gather/scatter, pre svega zbog fizickih ogranicenja L1 kesa. Ako je potrebno pokupiti 16 nesusednih podataka, single-ported L1 kes mora da ih cita jedan po jedan. L1 kes moze da se napravi sa dva load port-a sto bi omogucilo da citaju dva po dva podatka (ali pod ogranicenjem da ne dele isti bank). Praviti vise od 2 port-a je nezgodno i neisplativo.
No, uopste ni nije bitno da se gather/scatter ubrzava, jer se i racuna na to da ove instrukcije imaju veliko kasnjenje - kasnjenje koje procesor moze da sakrije pomocu multithreading-a. Jedno Larrabee jezgro moze da prati 4 thread-a. Dok jedan thread "trci" po memoriji za gather instrukciju, ostali mogu da se izvrsavaju nezavisno i tako ne ostavljaju jezgro besposlenim. Ovo efektivno sakriva kasnjenje gathere instrukcije.

 

[gx-x]

prvo pa musko!

welcome!

 

[audiofreak]

@thecookiemonster:

Dobrodosao na forum.

Mislim da nije toliko razlika u kolicini RAM-a, koliko u nacinu pristupa.

Adresiranje jeste CPU-like, medjutim i Larrabee ce imati hardverski texture unit, ako sam dobro shvatio upravo on bi trebao da radi gather i scatter?

Ima i Larrabee svog balasta: x86 kompatibilnost vuce sve od 16-bitne ere, sto deluje prilicno pointless.

Slazem se ali to na zalost ne moze da se promeni bez gubitka kompatibilnosti. Pritom ne mislim na 16 .vs. 32 bita nego na segment/ofset/selektor sistem i razne deskriptor tabele.

Ne mogu puno da urade povodom ubrzavanja gather/scatter, pre svega zbog fizickih ogranicenja L1 kesa. Ako je potrebno pokupiti 16 nesusednih podataka, single-ported L1 kes mora da ih cita jedan po jedan. L1 kes moze da se napravi sa dva load port-a sto bi omogucilo da citaju dva po dva podatka (ali pod ogranicenjem da ne dele isti bank).

Moze se racunati i na to da kod gather-a/scatter-a cesto vise lokacija pada u istu cache liniju pa nesto uraditi i po tom pitanju.

Praviti vise od 2 port-a je nezgodno i neisplativo.

Slazem se i sa tim. Medjutim:

No, uopste ni nije bitno da se gather/scatter ubrzava, jer se i racuna na to da ove instrukcije imaju veliko kasnjenje - kasnjenje koje procesor moze da sakrije pomocu multithreading-a.

Larrabee da, ali ne i obican procesor u kome bih ja voleo da vidim te instrukcije, njemu ce ubrzanje biti potrebno.

 

[thecookiemonster]

welcome!

Dobrodosao na forum.

Hvala na dobrodoslici.

Adresiranje jeste CPU-like, medjutim i Larrabee ce imati hardverski texture unit, ako sam dobro shvatio upravo on bi trebao da radi gather i scatter?

Larrabee-ov texture unit bi trebalo da radi iskljucivo texturni gather i filtriranje. Generalni gather/scatter i ostali ne-graficki specificni pristupi memoriji zaobilaze TU. Svako jezgro ima direktan pristup memoriji tacnije L1 kesu, a TU je dalje od jezgra na inter-core ring-u zajedno sa L2 kesom.

Slazem se ali to na zalost ne moze da se promeni bez gubitka kompatibilnosti. Pritom ne mislim na 16 .vs. 32 bita nego na segment/ofset/selektor sistem i razne deskriptor tabele.

Sreca je jedino sto jedan dekoder sluzi 4 thread-a, pa to efektivno smanjuje prostor koji zauzima legacy podrska. Uz to su stare instrukcije vecinom microcode umesto fastpath, na cemu se jos malo dobija. S druge strane, segmenti & co. nezaobilazno komplikuju jedinicu za generisanje adresa.
Nikako ne mogu da se oslobodim ideje da naprave samo jedno jezgro sa full legacy podrskom, dok bi ostala imala podrsku samo za moderne instrukcije. Tako bi sve legacy instrukcije preusmeravali na ono jedno jezgro. Ali ovo je bas toliko nemoguce koliko i zvuci

Moze se racunati i na to da kod gather-a/scatter-a cesto vise lokacija pada u istu cache liniju pa nesto uraditi i po tom pitanju.

Da, 16 razlicitih kes linija je worst case scenario, a ne norma.
Potencijalno bi jos i prefetcher mogao da pomogne u zavisnosti od load pattern-a.

Larrabee da, ali ne i obican procesor u kome bih ja voleo da vidim te instrukcije, njemu ce ubrzanje biti potrebno.

Intel ni nema nameru da uvede te instrukcije za obicne procesore tj. tacnije obicna jezgra (sem ako nisam nesto propustio kod AVX-a - Usput, koje je tvoje misljenje o AVX-u?). Ali mislim da mozes racunati da ce se za par godina pojaviti jedan heterogeni procesor koji ce imati npr. 4 jezgra potomka Nehalem-a + 16 jezgara potomka Larrabee-a. U takvoj konfiguraciji bi se mogle iskoristiti prednosti oba koncepta.

 

[audiofreak]

Larrabee-ov texture unit bi trebalo da radi iskljucivo texturni gather i filtriranje. Generalni gather/scatter i ostali ne-graficki specificni pristupi memoriji zaobilaze TU. Svako jezgro ima direktan pristup memoriji tacnije L1 kesu, a TU je dalje od jezgra na inter-core ring-u zajedno sa L2 kesom.

Jel imas neke reference za to? Voleo bih da procitam a ne stizem da jurim ovih dana od posla.

Intel ni nema nameru da uvede te instrukcije za obicne procesore tj. tacnije obicna jezgra (sem ako nisam nesto propustio kod AVX-a - Usput, koje je tvoje misljenje o AVX-u?).

Nisi propustio ali ja sam im predlozio da to ubace

AVX je skroz ok, trebao bi da olaksa programiranje.

 

[CooLa]

Vrlo je lepo sto vas dvojica znate sve to o cemu pricate... Ali postoje neki, kojima arhitektura procesora nije jaca strana... :p Dajte neke linkove ljudi !

Btw... Hoce li larrabee imati neke shader unite, ili?

 

[thecookiemonster]

Jel imas neke reference za to? Voleo bih da procitam a ne stizem da jurim ovih dana od posla.

http://download.intel.com/technology/architecture-silicon/Siggraph_Larrabee_paper.pdf
Definitivana referenca za Larrabee arhitekturu. Iz toga je (pre)pisano 99% tekstova na tech sajtovima.

http://software.intel.com/file/15542
http://software.intel.com/file/15545
Prezentacije sa GDC 09 o Larrabee New Instructions.

Vrlo je lepo sto vas dvojica znate sve to o cemu pricate... Ali postoje neki, kojima arhitektura procesora nije jaca strana... :p Dajte neke linkove ljudi !

Ja se uglavnom trudim da bude sto jasnije, ali moram da gledam da ni audiofreak-u ne dosadjujem. Poslednji put kad sam potpuno laicki objasnjavao zbog koristi vecine, audio mi je zamerio sto mu crtam

Sto se linkova tice, mislim da je ovde dat dosta dobar prikaz Larrabee-a: http://www.tomshardware.com/reviews/intel-larrabee-graphics,2253.html
Ima i na Anandu jedan tekst, ali mislim da ni njima samima nije jasno sta je tamo napisano.

Inace, koga zanima, da kazem, "tablica mnozenja" procesorske arhitekture, evo par linkova gde mislim da je lepo obradjena materija iz koje moze da se nauce osnovne:

Understanding the Microprocessor
http://arstechnica.com/paedia/c/cpu/part-1/cpu1-1.html
Understanding CPU caching and performance
http://arstechnica.com/articles/paedia/cpu/caching.ars
Pipelining: An Overview (Part I)
http://arstechnica.com/articles/paedia/cpu/pipelining-1.ars
Pipelining: An Overview (Part II)
http://arstechnica.com/articles/paedia/cpu/pipelining-2.ars
SIMD architectures
http://arstechnica.com/articles/paedia/cpu/simd.ars


Nesto malo naprednije:

The G4 and the K7 - an architectural look at two post-RISC processors
http://arstechnica.com/articles/paedia/cpu/g4vsk7.ars
Into the Core: Intel's next-generation microarchitecture
http://arstechnica.com/articles/paedia/cpu/core.ars

Hard core
Understanding the Detailed Architecture of AMD's 64 bit Core
http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html


A ovo je malo filozofski:

Understanding Moore's Law
http://arstechnica.com/articles/paedia/cpu/moore.ars
RISC vs. CISC: the Post-RISC Era
http://arstechnica.com/cpu/4q99/risc-cisc/rvc-1.html
The Future of x86 and the Concept of the Instruction Set Architecture
http://arstechnica.com/cpu/2q00/x86future/isa-future-1.html

Btw... Hoce li larrabee imati neke shader unite, ili?

Nece, ali tradicionalne "shadere" vise nemaju ni GPU-ovi od DirectX 10 pa navise.
To su sve u sustini samo ALU-i (aritmeticko logicke jedinice) koje mogu da vrse matematicke operacije (sabiranje, mnozenje itd.) ili logicke (I, ILI, negacija itd.). One izvrsavaju shader programe bilo da su pixel, vertex ili geometry. Nije im bitno koji od ta tri programa izvrsavaju jer nisu specijalizovane ni za jedan, vec generalne. Upravo se ta generalnosto novih GPU-ova iskoristiva za pokretanje GPGPU koda.
Tako i Larrabee poseduje izvrsne jednice koje moze da uposli bilo kojim poslom, pri cemu to moze biti i neki shader.

 

[audiofreak]

Njegovi shader uniti su x86 procesori. Dakle sve sto moze da se izvrsi na obicnom x86 procesoru bez ogranicenja po pitanju broja varijabli, iteracija u petlji, preciznosti proracuna (kao kod danasnjih GPU shadera), moze i na Larrabee.

 

[illidan]

Game Physics On Larrabee

 

[CooLa]

http://download.intel.com/technology/architecture-silicon/Siggraph_Larrabee_paper.pdf
Definitivana referenca za Larrabee arhitekturu. Iz toga je (pre)pisano 99% tekstova na tech sajtovima.

http://software.intel.com/file/15542
http://software.intel.com/file/15545
Prezentacije sa GDC 09 o Larrabee New Instructions.


Ja se uglavnom trudim da bude sto jasnije, ali moram da gledam da ni audiofreak-u ne dosadjujem. Poslednji put kad sam potpuno laicki objasnjavao zbog koristi vecine, audio mi je zamerio sto mu crtam

Sto se linkova tice, mislim da je ovde dat dosta dobar prikaz Larrabee-a: http://www.tomshardware.com/reviews/intel-larrabee-graphics,2253.html
Ima i na Anandu jedan tekst, ali mislim da ni njima samima nije jasno sta je tamo napisano.

Inace, koga zanima, da kazem, "tablica mnozenja" procesorske arhitekture, evo par linkova gde mislim da je lepo obradjena materija iz koje moze da se nauce osnovne:

Understanding the Microprocessor
http://arstechnica.com/paedia/c/cpu/part-1/cpu1-1.html
Understanding CPU caching and performance
http://arstechnica.com/articles/paedia/cpu/caching.ars
Pipelining: An Overview (Part I)
http://arstechnica.com/articles/paedia/cpu/pipelining-1.ars
Pipelining: An Overview (Part II)
http://arstechnica.com/articles/paedia/cpu/pipelining-2.ars
SIMD architectures
http://arstechnica.com/articles/paedia/cpu/simd.ars


Nesto malo naprednije:

The G4 and the K7 - an architectural look at two post-RISC processors
http://arstechnica.com/articles/paedia/cpu/g4vsk7.ars
Into the Core: Intel's next-generation microarchitecture
http://arstechnica.com/articles/paedia/cpu/core.ars

Hard core
Understanding the Detailed Architecture of AMD's 64 bit Core
http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html


A ovo je malo filozofski:

Understanding Moore's Law
http://arstechnica.com/articles/paedia/cpu/moore.ars
RISC vs. CISC: the Post-RISC Era
http://arstechnica.com/cpu/4q99/risc-cisc/rvc-1.html
The Future of x86 and the Concept of the Instruction Set Architecture
http://arstechnica.com/cpu/2q00/x86future/isa-future-1.html



Nece, ali tradicionalne "shadere" vise nemaju ni GPU-ovi od DirectX 10 pa navise.
To su sve u sustini samo ALU-i (aritmeticko logicke jedinice) koje mogu da vrse matematicke operacije (sabiranje, mnozenje itd.) ili logicke (I, ILI, negacija itd.). One izvrsavaju shader programe bilo da su pixel, vertex ili geometry. Nije im bitno koji od ta tri programa izvrsavaju jer nisu specijalizovane ni za jedan, vec generalne. Upravo se ta generalnosto novih GPU-ova iskoristiva za pokretanje GPGPU koda.
Tako i Larrabee poseduje izvrsne jednice koje moze da uposli bilo kojim poslom, pri cemu to moze biti i neki shader.

Procitao skoro sve... Slobodno mozete da nastavite sa diskusijom !

 

[illidan]

32 jezgra

 

[illidan]

Larrabee offers about the same performance as GTX 285

Larrabee marks Intel’s re-entry into discrete video card market. Intel’s earlier attempt was unsuccessful one. Intel is hoping that Larrabee with its x86 architecture, would give it a benefit over GPUs from Nvidia and AMD which use technologies such as CUDA and Stream respectively to compute tasks such as Folding and Video Encoding. Tom’s is reporting that during the ongoing Computex, they managed to get an Intel partner to speak up on Larrabee. According the the details revealed, Larrabbee’s current performance is similar to Nvidia’s GTX 285. If this is true, this would mean that AMD and Nvidia’s new GPUs, due in a few months, will end up to be faster than Larrabee. This is not a bad thing for Intel, if they can price it right and cater to the mainstream.

izvor

 

[Lukija]

Intel Larrabee might be delayed to Summer 2011 ?

[abbr=Intel Larrabee might be delayed to Summer 2011]LINK[/abbr]

 

[drfedja]

Mozda ipak kompleksnost i relativno niske performanse predstavljaju problem, cekaju 32 ili 22nm.

 

[audiofreak]

Meni obecane performanse GTX-a uopste nisu niske za prvi CGPU (ili GCPU).

 

[drfedja]

Perfrormanse GTX-a sada mozda nisu niske, ali sledece godine to vec nije to. Koliko se secam, ljudi iz Intela prosle godine na jednoj prezentaciji su mi rekli kako ce Larrabee po performansama ostavljati sve konkurente iza sebe. Izgleda da to nece biti tako lak posao.

 

[audiofreak]

Perfrormanse GTX-a sada mozda nisu niske, ali sledece godine to vec nije to. Koliko se secam, ljudi iz Intela prosle godine na jednoj prezentaciji su mi rekli kako ce Larrabee po performansama ostavljati sve konkurente iza sebe. Izgleda da to nece biti tako lak posao.

Pod uslovom da NVIDIA izbaci nesto bolje od tog GTX-a, a koliko vidim upiru se iz petnih zila ali ne ide. Cenim da je GPU dosegao isti onaj zid kao i single core CPU-ovi pre koju godinu i da je potrebno nesto radikalno drugacije da bi imali opet neko dupliranje performansi kao sto je to bilo sa 8800GTX.

Uzgred, procesori ponovo polako pristizu (negde i prestizu) GPU-ove u mlevenju brojeva zahvaljujuci dobroj optimizaciji koja je za GPU misaona imenica jer ima suvise faktora (OS, drajveri, programski jezik, shader kompajler, brzina transfera host<->gpu, sam kod, itd) koji uticu na performanse. Godina Larrabee-ja ce cini mi se biti jako zanimljiva.

 

[drfedja]

Pod uslovom da NVIDIA izbaci nesto bolje od tog GTX-a, a koliko vidim upiru se iz petnih zila ali ne ide. Cenim da je GPU dosegao isti onaj zid kao i single core CPU-ovi pre koju godinu i da je potrebno nesto radikalno drugacije da bi imali opet neko dupliranje performansi kao sto je to bilo sa 8800GTX.

Verovatno da je limit dosegnut bas zbog faktora koje si dole naveo, a to su pre svega OS, drajveri, programski jezik, shader kompajler.

Cinjenica je da je nVidia napravila skok kada su presli na unified shader arhitekturu. Koriscenje procesorskih jezgara je jos jedan korak u tom smeru i nacin da se preskoce neki od ovih slojeva.

 

[audiofreak]

Evo jednog videa sa proslogodisnjeg IDF-a gde se pominje Larrabee (poslednja trecina):
Link (18,768KB)

Ko me zna iz vidjenja neka se malo pazljivije zagleda u 5:39

 

[monteboy]

NVidia sunca videci nece toliko vam mogu reci....
R800 ce biti cistokrvni dualgpu sto naravno nalaze na razmishljanje i spekulacije .....
Jer ukoliko AMD smesti dve takve zverke na jednu karticu .....

imali bi smo

ATI Radeon HD 5870 X4

A onda laku noc Nvidia i Wonnabee .....

Imajuci to u vidu postavlja se pitanje sta je mislio Intel kad je govorio o ostavljanju konvencionalnog GPU'a iza sebe ?

 

[audiofreak]

E ako to nije sto puta do sada prezvakano... bar ti bi trebao to da znas.

 

[S.T.A.R.A.C.]

http://www.pcper.com/comments.php?nid=7531

In a move that is surely going to raise some eyebrows, Intel has apparently decided to add a pair of HD video decoders to the logic on-board the Larrabee graphics chip; this according to a story over at SemiAccurate. This would definitely go against the whole premise of the Larrabee architecture: to do as much work as possible in x86 software without the need for dedicated hardware to any one specific task. Intel said from the beginning that textures required special hardware to run most efficiently but now that Intel has decided HD decoding is too inefficient on the platform, you can't help but wonder if there are other tasks with the same fate.

Sta kazes Audio na ovo