SG.hu·

Intel: 32 magos lesz az első Larrabee

A processzorgyártó megtörte a csendet, és egy rendezvényen bemutatta az első képet a készülő sokmagos fejlesztéséről, amely az nVidia és az AMD grafikus vezérlőivel veszi majd fel a versenyt.

A németországi rendezvényen megjelent lapoknak köszönhetően az interneten is felbukkant a bemutatott kép (valamint további illusztrációk), amely az első változatot ábrázolja. Szakértők megvizsgálták a képet, és több fontos megállapítást tettek azzal kapcsolatban. Ebből megtudhatjuk, hogy nagyjából mire is számíthatunk a hivatalos rajt pillanatában.



A cég mindössze annyit árult el, hogy a debütálásra idén nem kerül majd sor, ehelyett 2010 elején dobják piacra az első elkészült példányokat. A képek alapján a külső szakértők szerint ez egy 32 magos változat lesz, amely kizárólag x86 chipekre épül (amelyeket úgynevezett vector processing egységekkel párosítanak). A Larrabee emellett megosztott gyorsítótárra támaszkodhat majd, a kapcsolódó memória kezeléséért pedig a széleken elhelyezett vezérlők lesznek majd felelősek. Arról pedig már korábban megjelentek hírek, hogy május végén érkezik a Parallel Studio névre keresztelt grafikai fejlesztői eszköztár, erről azonban most nem beszéltek.

Az Intel saját hivatalos oldalán már idejekorán elérhetővé tette a Larrabee részletes dokumentációját, amelyből jól látható, hogy akár 64 magos felépítéssel is számolhatunk - a magok száma tehát széles skálán mozoghat, ez a különböző változatokon lehet majd 8, 16, 32, 48, illetve 64. A cég arra tett ígéretet, hogy a programozhatóság terén a kényelemre és a rugalmasságra építenek, itt szerintük sikerül majd a jelenleg használt dedikált grafikus vezérlőkhöz képest jobb szintet elérni.

Az első generáció a High-K 45 nanométeres gyártástechnológiával készül, 32 nanométerre (és nyilván több magra) később váltanak majd.

Kapcsolódó cikkek és linkek

Hozzászólások

Jelentkezz be a hozzászóláshoz.

© Vers2009. 05. 19.. 17:27||#27
akkor beszéljünk az irregular shadow maprol 😊
© A12748152009. 05. 19.. 10:37||#26
HLSL/GLSL/Cg alatt igen, de az assemblyje is viszonylag kényelmes.
© Sanyix2009. 05. 19.. 09:17||#25
Mintha most nem lenne olyan egyszerû egy shader kódot írni, mint c#-ban programozni... fõleg dx11-ben.
© A12748152009. 05. 19.. 00:27||#24
És akkor még a TEX utasításokat nem is veséztük ki (1D, 2D, 3D, CUBE, Rectangle, 1DArray, 2DArray, CUBEArray, 4D), amiket ugye HW-sen tuda GPU, ráadásul, Bilinear, MIPmapping, Trilinear, Anisotróp, PCF szûrõkkel együtt, sõt DX10.1-tõl van támogatásrá, hogy gyorsabban lehesen akár milyen szûrõt implementálni pixel shaderben.
© A12748152009. 05. 19.. 00:23||#23
"Egy shader utasitas leforditva altalaban 1 vektor muvelet lesz, ..."

Khm.

DP3 utasítás
__asm
{
mulps xmm0, xmm1;
haddps xmm0, xmm0;
haddps xmm0, xmm0;
}

DP4 utasítás
__asm
{
mulps xmm0, xmm1;
haddps xmm0, xmm0;
haddps xmm0, xmm0;
haddps xmm0, xmm0;
}

CRS/XPD utasítás:
__asm
{
movaps xmm2,xmm0;
movaps xmm3,xmm1;
shufps xmm0, xmm0, 0x8d;
shufps xmm1, xmm1, 0x1e;
mulps xmm0, xmm1;
shufps xmm2, xmm2, 0x1e;
shufps xmm3, xmm3, 0x8d;
mulps xmm2, xmm3;
subps xmm0, xmm2;
}

MAD utasítás
madaps xmm0, xmm1, xmm2; //x64 only

Ráadásul a GPU utasítások 3 címes gépekkel modellezhetõek, míg az x64/x86 2 címes gépekkel.
© kvp2009. 05. 18.. 23:29||#22
"Na már most egy modern GPU tényleg GFLOPS felett van már, így nem értem hogy lesz Larrabee high end verziód, 1024 GPU teljesítményû?"

1024 gpu mag teljesitmenyu. Azaz a high end valtozat kb. egy mai dx10-es nvidia cpu teljesitmenyenek a negyszereset hozza majd. Az alap larrabee pedig eppen hogy eleri a mai 256 magos nvida gpu-k teljesitmenyet, ami nem szamit olyan rossz adatnak. Mindezt ugy, hogy 16 cpu es cpu magonkent 16 alu lesz benne, ami 256 gpu-s alu-nak felel meg, 16-os shader szal kotegekkel. (ehhez hasonlo az nvidia megoldasa is)

Egy shader utasitas leforditva altalaban 1 vektor muvelet lesz, ami egyszerre max. 16 shader szalat tud igy futtatni, a jelenlegi x86-ok 8 szalaval szemben, tovabba hardverbol tamogatnak majd nehany csak gpu-k eseten szukseges matematikai muveletet is, ami az altalanos celu x86-osokbol eddig kimaradt es csak emulalni lehetett. A branch egyseg az nvidia minajara a kozponti magokban kap helyett, tehat a 16 shader szal csak egyszerre tud branch-elni (mivel valojaban a 16 shader 1 valodi cpu-n fut vliw-es vektor utasitaskent). Az egyszerubb if/then/else megoldasokat loop unrolling-al es conditional store-okkal lehet linearizalni, ami bizonyos bonyolultsagig lehetove teszi a teljesitmenyvesztes nelkuli elagazasos shader programok irasat.

A lenyeg az, hogy mindezt hagyomanyos x86-os kornyezetben lehet megtenni, ami azt jelenti, hogy a larrabbe extra tudasa elerheto lesz minden felhasznaloi program szamara (mint ahogy az mmx/sse utasitasok is). Mindezt specialis fejlesztoi kellekek es barmifele trukkozes nelkul. (tehat nyugodtan lehet majd akar c++-ban vagy c#-ban shader alapu kodot irni, mivel a larrabee is csak egy sima x86 lesz, csak sok maggal es uj multimedias utasitasokkal, mint a pentium ota az osszes intel cpu)
© A12748152009. 05. 18.. 23:22||#21
"Láttam én annó GF4MX-re is olyan demo-t ami tele volt shader szerû megoldásokkal, pedig a kártya amúgy ilyet nem tudott, elvileg."

Pedi igen, TNT 2 óta tudott olyat, csak nagyon primitív, textúra címzéssi lehetõségekkel nem rendelkezett, úgy hívták Register Combiner, bár dot3 bump-hoz nem kellett, meg volt ATI-kon is meg NV is még az EnvCombiner.
© Julius Caesar2009. 05. 18.. 21:27||#20
ez a másik... ha egy termék életciklusa 2+ év lenne, akkor nem ekkora lenne egy (mellesleg tök unalmas, de ezt már 1000000x ki van tárgyalva) mai játék gépigénye, hanem fele akkora. de hát üzlet az üzlet.
© NEXUS62009. 05. 18.. 15:51||#19
Hát nekem is van olyan érzésem, hogy adott nagyságú sziliciumból, adott technológián kb mindenki max ugyan azt tudja kihozni. Ha valamire rágyúr, akkor másban kell engedni. A jobb programozhatóság, az végül az elérhetõ max teljesítmény rovására megy.
Lásd X360 vs PS3 architektúra, ami elõször elõny, az hátrányt okoz a jövõben és fordítva.
PC-nél persze semelyik termék nem jut el odáig, hogy komolyan kelljen a programok optimalizálásán gondolkodni, ergó, ha amúgy is rövid a ciklusidõ, akkor a max teljesítménnyel szemben a könnyû programozhatóság jelent valós elõnyt.
Láttam én annó GF4MX-re is olyan demo-t ami tele volt shader szerû megoldásokkal, pedig a kártya amúgy ilyet nem tudott, elvileg. A kutyát nem érdekelte, hogy mi a grafkártya valós teljesítménye, mert mire a játékok odáig jutnak, már 2 generációval odébb járunk.

Amúgy hasonló megoldásokkal valszeg más cég pl. IBM is foglalkozik (valami fejlettebb cell-lel), csak nem csinálnak akkora felhajtást körülötte.
© Julius Caesar2009. 05. 18.. 14:29||#18
de ugye ezt Róma dicsõségére teszik? <#taps>

majd meglássuk, még nem tudhassuk mit fejlesztenek.