Gyurkity Péter

Jövőre készülhet el az Intel grafikus erőműve

Az erőmű szóval jellemezhető leginkább a cég készülő Larrabee fejlesztése, amelynek első példánya a jövő év elejére állhat majd készen. Addig is a szoftveres háttérrel nyújtanak betekintést a fejlesztők számára.

A külső beszámolókból megtudhatjuk, hogy az Intel végre érdekes részletekkel állt elő saját fejlesztésével kapcsolatban, mégpedig a Game Developers Conference alatt, ahol is elárulták, hogy nagyjából mivel vennék fel a versenyt a grafikus kártyák piacán az nVidia és az AMD/ATI termékeivel. A sokmagos felépítésről szóló hírek miatt néhány pont nem túl meglepő, ám a cég részéről brutális erőt ígérnek.



Elöljáróban leszögezték, hogy egyelőre még nem áll készen a Larrabee chip, vagyis nincs még működő prototípus, ez legkorábban az idei év végére, avagy a következő év elejére készülhet el. A fejlesztők jó része még bizonyos tervezési kérdésekről konzultál, abban azonban már most biztosak, hogy a játékok mellett olyan speciális fejlesztéseket is ki szeretnének szolgálni, amelyek különösen nagy hasznát vennék a sokmagos felépítésnek. Ezek között szerepel a Dreamworks, amely a renderelési és animációs feladatokban számít a kiemelkedő számítási teljesítményre - a Nehalem chipek itt nagy lökést adtak a projektnek, ám a Larrabee révén érhetik majd el a többé-kevésbé ideális állapotot.

Az első példányok tulajdonképpen a hagyományos grafikus vezérlőkre hasonlítanak majd, még külsőben is, a nagy különbség az lesz, hogy a központi processzorok magjaira helyezik a hangsúlyt, ezekből meglehetősen sokat passzíroznak majd egy-egy szilíciumlapkára, az egyes magok között pedig nagy sávszélességű kapcsolatot biztosítanak. A vector és a scalar egység egyszerre hajthat végre különböző műveleteket, előbbi pedig órajelenként akár 16 lebegőpontos számítást is elvégezhet, és akkor még csak egyetlen ilyen egységet említenek, miközben a felépítés révén jóval több lesz belőlük.

A külső fejlesztők számára hamarosan elérhetővé teszik a hivatalos oldalon a prototípus szerepét betöltő C++ library állományt, amely a készülő chip teljes funkcionalitását biztosítja majd számukra - szoftveres úton.

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)
  • dez #36
    "A larrabee-k eseten annyi memoria buszt tesznek ra amennyik akarnak. A jelenlegi nvidia chipeken is 2-8 fuggetlen csatorna van. Igy akar mindegyik cpu tomb kaphat egy vezerlot."

    Ezt a Cellel is meg lehet tenni. Annál is inkább, mert XDR vezérlője van, amihez sokkal kevesebb vezeték kell. Most is többcsatornás.

    "A forditoprogramokat erre talaltak ki. A forditot megirja egy ember, aztan hasznalja tobb szazezer."

    Na ne mondd, tényleg? Akkor mondanál egy olyan fordítót, ami automatikussá teszi a cache-manipuláció optimizálást? Csak mert én nem tudok ilyet. Mellesleg a Larrabee-ban a megszokottnál spécibb utasítások vannak erre.

    "A masik, hogy ha nem akar valaki jo kodot irni, akkor egyszeruen kihagyja az optimalizalast. Lehet, hogy nem lesz tul gyors a program, de elkeszul idore. Ez utobbi fontosabb a kiadok szamara, mint az optimalizalas."

    Az is fontos, hogy ne legyen használhatatlan a kód, szóval elkerülhetetlen az optimizálás. Pontosabban, eleve ezt figyelembe véve kell megírni a kódot. Más szóval, a hagyományos kódok bár elfutnak rajta, de igencsak lassacskán.

    "Nem igaz, ez csak az adatok lokalitasatol fugg."

    De igaz, egy adott szóhoz tartozó cache-line mindig hosszabb, mint maga a szó, hiszen különféle kiegészítő adatokat is tárolni kell.

    "Pont az ami a cell-nel kotelezo, az x86-osok eseten pedig csak a teljesitmenyt novelo opcionalis megoldas."

    Mi kötelező? Nem tudom, mire gondolsz.

    "Ezert van a jelenlegi rendszereknel 1 orajeles cache es ezert van a larrabee-ben smt, hogy amig az egyik szal var az adatra, addig a masik szal dolgozik."

    Igen, a HW SMT kompenzálja az in-order rendszert. Azonban, ennek megvan az ára is: párhuzamosan végrehajtható szálanként külön regiszterbank, ami igencsak megnöveli a magméretet. A Larrabee-nél ráadásul 4 párhuzamos szál van, és gondolom 512 bitesek a regiszterek is.

    "Es mindezt teljesen automatikusan, a programozo szamara gondot nem jelento modon teszi."

    A gond ott van, hogy az amúgy sem nagy cache-t is 4-felé kell osztani.

    "(tehat akar arra is kepes, hogy egy utasitast az egyik szalbol, egyet a masik szalbol hajtson vegre, ezt cell-el nem lehet megoldani, mert csak szoftveres szal valtas van az spe-kben, ami jopar utasitast igenyel)"

    Nem baj, mert nincs is rá szükség. A double-bufferes feldolgozás viszont minden további nélkül megoldható, elhanyagolható overheaddel.

    "A larrabee-ben pont ezert van smt, hogy ez elony legyen ne hatrany"

    Ezt az SMT nem igazán befolyásolja, mivel az a 16 db művelet párhuzamosan hajtódik végre.

    "tovabba az osszes gpu-ban is ezert van 16-os parhuzamositas az spu-k 2-es megoldasa helyett."

    Nem, egyátalán nem ezért. Hanem azért, mert túl sok helyet igényelne, ha több ütemező és branch unit lenne. Azaz ez egy kompromisszum.

    Az SPU-k 4db SP FP vektorműveletet tudnak párhuzamosan.

    "Kar, hogy ehhez ujra kell irni, de legalabb ujraforditani a szoftvert. Ezzel szemben az x86-os kod annyi szalat hasznal amennyit akar, aztan ha van eleg mag, akkor mindegyik kap sajatot, ha nincs akkor futnak kevesebben, multitask-ban. Igy a lassabb gepeken is fut a kod, de ha veszunk egy ujat, akkor magatol gyorsabb lesz minden regi program."

    Lásd amit fent írtam. Megfelelő tervezés és optimizálás nélkül itt is lassú lenne a kód.
  • kvp #35
    "- Az egy dolog, hogy a közvetlen memóriacímzés által egy átlag C kód fordítható és futtatható rajta, de ha ezt tesszük, nagyon gyorsan beleütközünk a memória-sávszélesség korlátaiba. És akkor ugyanúgy neki kell állni optimalizálni, a minimumra csökkenteni a memóriahozzáférések számát."

    A larrabee-k eseten annyi memoria buszt tesznek ra amennyik akarnak. A jelenlegi nvidia chipeken is 2-8 fuggetlen csatorna van. Igy akar mindegyik cpu tomb kaphat egy vezerlot.

    "De mivel itt cache van, tele kell tenni a kódot prefetchekkel, flushokkkal, stb. stb. Akkor már sokkal átláthatóbb, ha van minden maghoz egy belső, címezhető ramunk..."

    A forditoprogramokat erre talaltak ki. A forditot megirja egy ember, aztan hasznalja tobb szazezer. A masik, hogy ha nem akar valaki jo kodot irni, akkor egyszeruen kihagyja az optimalizalast. Lehet, hogy nem lesz tul gyors a program, de elkeszul idore. Ez utobbi fontosabb a kiadok szamara, mint az optimalizalas.

    "- Cache memóriából 256 KB sokkal kevesebb hasznos adatot v. kódot tud tárolni (mert egy adat-szót tartalmazó és azonosító cache-line sok szó önmagában), mint 256 KB lokális RAM."

    Nem igaz, ez csak az adatok lokalitasatol fugg. Pont az ami a cell-nel kotelezo, az x86-osok eseten pedig csak a teljesitmenyt novelo opcionalis megoldas.

    "- Mindkettő in-orderes, de a Larrabee-nél ez jóval többször jelenthet várakozást, mivel az SPU-k alapvetően a cache-sebességű lokális memóriába dolgoznak, ahol ez nem számít."

    Ezert van a jelenlegi rendszereknel 1 orajeles cache es ezert van a larrabee-ben smt, hogy amig az egyik szal var az adatra, addig a masik szal dolgozik. Es mindezt teljesen automatikusan, a programozo szamara gondot nem jelento modon teszi. (tehat akar arra is kepes, hogy egy utasitast az egyik szalbol, egyet a masik szalbol hajtson vegre, ezt cell-el nem lehet megoldani, mert csak szoftveres szal valtas van az spe-kben, ami jopar utasitast igenyel)

    "- Nem hátrány, hogy az SPU-kban 128 bites vektoregység van: 1. kevesebb párhuzamos műveletre esik 1-1 ugrási egység, így kevesebbet is fog vissza, ha ugorni kell, 2. így kisebb is a mag."

    A larrabee-ben pont ezert van smt, hogy ez elony legyen ne hatrany, tovabba az osszes gpu-ban is ezert van 16-os parhuzamositas az spu-k 2-es megoldasa helyett.

    "- Az SPU-k kisebbek: több fér el. Azonos csíkszélességen mindig több SPU fog elférni."

    Kar, hogy ehhez ujra kell irni, de legalabb ujraforditani a szoftvert. Ezzel szemben az x86-os kod annyi szalat hasznal amennyit akar, aztan ha van eleg mag, akkor mindegyik kap sajatot, ha nincs akkor futnak kevesebben, multitask-ban. Igy a lassabb gepeken is fut a kod, de ha veszunk egy ujat, akkor magatol gyorsabb lesz minden regi program.
  • dez #34
    Csak éppen sokkal lassabban.
  • dez #33
    Elég alacsony színvonalú "elemzés". Ami nem jutott el az agyáig (bár tiédig sem, mert ugye hiába is írtam már le ezeket neked, de most hátha):
    - Az egy dolog, hogy a közvetlen memóriacímzés által egy átlag C kód fordítható és futtatható rajta, de ha ezt tesszük, nagyon gyorsan beleütközünk a memória-sávszélesség korlátaiba. És akkor ugyanúgy neki kell állni optimalizálni, a minimumra csökkenteni a memóriahozzáférések számát. De mivel itt cache van, tele kell tenni a kódot prefetchekkel, flushokkkal, stb. stb. Akkor már sokkal átláthatóbb, ha van minden maghoz egy belső, címezhető ramunk...
    - Cache memóriából 256 KB sokkal kevesebb hasznos adatot v. kódot tud tárolni (mert egy adat-szót tartalmazó és azonosító cache-line sok szó önmagában), mint 256 KB lokális RAM.
    - Mindkettő in-orderes, de a Larrabee-nél ez jóval többször jelenthet várakozást, mivel az SPU-k alapvetően a cache-sebességű lokális memóriába dolgoznak, ahol ez nem számít.
    - Nem hátrány, hogy az SPU-kban 128 bites vektoregység van: 1. kevesebb párhuzamos műveletre esik 1-1 ugrási egység, így kevesebbet is fog vissza, ha ugorni kell, 2. így kisebb is a mag.
    - Az SPU-k kisebbek: több fér el. Azonos csíkszélességen mindig több SPU fog elférni.

    Persze lehetnek feladatok, ahol az egyik, és olyanok, ahol a másik alkalmazása a hatékonyabb.

    Egyébként a GPU-k blokkjait ne nevezd magoknak, mert a processzor mag fogalmába jóval többminden tartozik, mint ami 1-1 ilyen blokkban van. Azok csak "egyszerű" ALU-k blokkjai. Az ütemező, és sokminden más külön funkcionális egységben van.
  • IMYke2.0.0.0 #32
    RAYTRACING ALAPOK
  • Sanyix #31
    2x-es pontossággal tudnak.
  • tomcsa4 #30
    A mai GPU-k egyszeres pontossággal tudnak számolni (lebegőpontos számítás, 32 bit). Gondolom a Larrabee ezen javít majd. De várok még több infót is. Remélem csacsognak még valamit.
  • kvp #29
    Hozzatennem, hogy a jelenlegi nvidia gpu-k is 16 magonkent vannak 1 valodi gpu maghoz csatolva, tehat 16 mag kap 1 elagazasi egyseget. Ez megfelel egy altalanos cpu-nak egy 16 magos simd vektor egyseggel. Jelenleg az nvidia-nal 256 magos gpu-kat gyartanak, ami kb. 16 darab azonos orajelu larabee magnak felel meg. Az egyetlen gond a ringbus-bol adodhat, ez mar a cell-eknek sem hasznalt, viszont mivel a larrabee-nel x86-okrol van szo, ezt barmikor ki lehet cserelni crossbar-ra a szofverek modositasa nelkul.

    Egy erdekes osszehasonlitas, a korabban belinkelt cikkbol:
    "It’s very tempting to compare Larrabee and Cell. Both use a multitude of single cores (in-order), putting the accent on vector calculation, 256 KB of dedicated memory per core, a ring bus to connect it all, etc. The similarities are numerous at first glance. Yet, the differences are also substantial: The Cell is first and foremost a CPU. Although it’s oriented toward streaming-type applications, it is not intended for rendering calculation, and consequently, there are no texture units.


    Zoom

    Another major difference is in the way memory is managed. On the Cell, except for the PPE, which is the only part of the processor that has a global vision of the memory space, all the SPU's memory accesses are limited to 256 KB of local store memory. So, access to main memory must be done explicitly via direct memory access (DMA) operations. Conversely, as we saw earlier, all of Larrabee’s cores have access to the entire memory space, via a cache memory whose management is transparent to the programmer, even if the programmer does have a certain form of control. Intel’s choice greatly simplifies programming and avoids having to include a more generalist core like the PPE. This heterogeneous system is one of the Cell’s handicaps, since it complicates things for the programmer. In addition to explicit management of memory, he or she must also build two executables using two different sets of instructions, which means using two different compilers.

    So Larrabee’s cores are much more complete than the Cell’s SPUs, since they support all the x86 instructions. However, their performance is also better in terms vector calculation. That’s because they operate on 512-bit vectors instead of the SPUs’ 128 bits, and while the Cell should have the advantage in clock frequency (Larrabee is expected to clock at 2 to 2.5 GHz, but that’s still very hypothetical), that doesn’t compensate for such a big disadvantage.
    ...
    What’s more, despite the flexibility GPUs have gained, their functionalities remain heavily oriented towards raw calculation. For example, there’s no question of performing I/O operations from a GPU. Conversely, Larrabee is totally capable of that, meaning that Larrabee can directly perform printf or file-handling operations. It’s also possible to use recursive and virtual functions, which is impossible with a GPU."
  • JZO #28
    Mennyi lesz a fogyasztása? Csak nehogy az "erőműhöz" erőmű kelljen!
  • JTBM #27
    Ha valakit érdekel infó:
    Toms Larrabee Review
    Egyenlőre még kísérleti fázisban van, nem lehet tudni, hány mGPU-ból is áll majd össze.

    Valószínűleg tényleg a Raytracing-et fogja célozni.

    Amint kijött és működik, valószínűleg el kezdenek majd dolgozni az optimalizációján, megnézik, hogy az x86-os magok valójában mit használnak és a nem használt részeket kidobják belőlül.

    Szóval a Larrabee II szvsz. sokkal gyorsabb lesz majd az elsőnél.