Gyurkity Péter

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.

Hozzászólások

A témához csak regisztrált és bejelentkezett látogatók szólhatnak hozzá!
Bejelentkezéshez klikk ide
(Regisztráció a fórum nyitóoldalán)
  • Vers #27
    akkor beszéljünk az irregular shadow maprol :)
  • A1274815 #26
    HLSL/GLSL/Cg alatt igen, de az assemblyje is viszonylag kényelmes.
  • Sanyix #25
    Mintha most nem lenne olyan egyszerű egy shader kódot írni, mint c#-ban programozni... főleg dx11-ben.
  • A1274815 #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.
  • A1274815 #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.
  • kvp #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)
  • A1274815 #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 Caesar #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.
  • NEXUS6 #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 Caesar #18
    de ugye ezt Róma dicsőségére teszik?

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