Új hozzászólás Aktív témák

• #55 Meteorhead aktív tag Abu85 #53

  Új Válasz 2011-12-09 11:27:42 #55

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Meteorhead

  aktív tag

  válasz Abu85 #53 üzenetére

  Ez persze rendben van. De mint OpenCL programozó, számomra megváltásként érkezik, hogy nem kell majd vért izzadva vektorizálni kódot, mert VLIW végrehajtók helyett skalár végrehajtók lesznek. Persze, a compiler megpróbál auto-vektorizálni adatfüggőség alapján, de vannak algoritmusok ahol borzasztó rossz eredményt ad. Ezért nagyon félrevezető a vektor jelleg, mert egy szál skalárműveletekkel operál.

• #50 Meteorhead aktív tag Abu85 #40

  Új Válasz 2011-12-09 10:42:09 #50

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Meteorhead

  aktív tag

  válasz Abu85 #40 üzenetére

  Tisztában vagyok vele, hogy VLIW nem teljesen vektorfeldolgozó (különbség annak aki nem tudná, vektorfeldolgozók ugyanazt az utasítást küldik le a sávok mentén, csak más adaton, míg VLIW (Very LongIntruction Word) egy utasításba pakol különböző műveleteket, amik egyszerre tudnak végrehajtódni a feldolgozón).

  A SIMD kifejezéseket lehet használni, de talán az egyszerűség kedvéért érdemes félretenni őket. Amit mondasz, az majdnem igaz, de mégsem. Azért nem igaz a 4 db 512 bites vektorfeldolgozó, mert az igaz, hogy ugyanazon műveleteket hajtják végre más-más adaton, de elágazni vektor jelleggel nem lehet, ezek meg külön szálak, amik el tudnak ágazni egymástól. (if-else, és igen, azt is tudom hogyan korlátozódik ez GPUn)

  Fermi végrehajtókban dedikált INT és FP skalárvégrehajtó van (amik akár egyszerre is dolgozhatnak), ezekből van 32 egy CU-ban, ennyi tud egyszerre futni, ezért 32 a warp-size.

  Evergreen (VLIW5) esetében 16 darab 5 széles VLIW egység van, ahol 16 szál tud igazából egyszerre futni, de 64-nél kevesebbet nem tud kezelni egy CU, ezért ekkora a wavefront-size. Ezek a szálak képesek vektorműveletre, de a VLIW jelleg miatt ennél bonyolultabb dolgokat is tudnak csinálni.

  Northern Islands (VLIW4) kiiktatja a speciális egységet, és a transzcendens műveleteket (MOD, SIN, COS, ...) három mezei végrehajtó összekapcsolásával érik el. Így mezei műveletekre nagyobb kapacitás marad.

  Southern Islands sokkal jobban hasonlít Fermire, avval a különbséggel, hogy itt nincs dediktált INT és FP egység, hanem ugyanaz a végrehajtó végzi mindkettőt. Egy CU-ban most már nem 16 VLIW4 feldolgozó van, hanem 4 darab külön életet élő 16 utas SIMD. De ez azért több egy 64 utas SIMD-nél, mert a 4 fürt SIMD egység egy CU-n belül tényleges elágazást is végezhet egymástól, sőt akár halál más dolgot is számolhatnak. Az nincs megkötve, hogy ugyanazt a shadert (vagy kernelt) kell futtatniuk. A CU definíciójában csak az van, hogy közös memóriaterületet szolgáltat a benne lévő szálak számára Az nincs benne, hogy azoknak a szálaknak egy wavefront/war-ból kell hogy származzanak, sőt még az sem, hogy ugyanannak a kódnak kell lennie.

  A hozzászólásod egyébként túlnyomó többségben igaz, nagyrészt csak kötekedem, de szerintem így talán tisztábban látni a különbségeket, mert vannak bőven.

• #34 Meteorhead aktív tag wetomi #28

  Új Válasz 2011-12-09 09:50:14 #34

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Meteorhead

  aktív tag

  válasz wetomi #28 üzenetére

  Hát az AMD linuxos támogatásáról inkább ne is beszéljünk... én linuxra fejlesztek tudományos szimulációkat, hozzáértő embernek tartom magam, és valami botrány ami linux oldalon történik a driverekkel. (Most a Windows-os driverek is trágyák, de linuxra a feature-ök rendre később érkeznek. Számomra is rejtély hogy miért.)

  AMDs fejlesztői fórumon egész komoly parasztlázadás tört ki, annyira xarok a driverek. Bugosak, helyenként hibás eredményeket adnak, szénné fagyna a gépek tőlük, van hogy bootolni sem képes linuxot... botrány.

• #14 Meteorhead aktív tag

  Új Válasz 2011-12-09 09:07:05 #14

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Meteorhead

  aktív tag

  "Mindenesetre a hírek arról szólnak, hogy 32 darab CU, azaz Compute Unit lesz benne, ami a korábban használt számozás értelmében 2048 darab shader processzornak felel meg. Az AMD valószínűleg így fog majd a feldolgozók számára utalni, de valójában ez technikailag nem helyes, ugyanis egy CU-ban négy darab 512 bites vektorfeldolgozó található, vagyis nem beszélhetünk skalár egységekről a GCN architektúra esetében."

  Olvasnak a fiúk neten?? GCN egyik legdurvább újítása, hogy lecserélik a shadereket skalár feldolgozóra! Eddig 4 széles vektor feldolgozók voltak, amiből volt 16 egy CUn. Ezek futtattak 64 szálat "egyszerre" (16+16+16+16 egymásután, mert regisztert 4 órajel elérni). GCN-ben felbontották a vektor végrehajtót, és négy wavefront fut egyszerre. Ez annak felel meg, mintha régi architektúrán négy szálat küldenénk a feldolgozón keresztül, egyet-egyet minden vektor sávon. De ez nem vektorfeldolgozó!!! 40 program counter van egy CU-n, ami 40 paralell futó wavefrontot enged (2560 szál!) amiből 256 aktív egy adott pillanatban. Minden shader külön azonosítóval rendelkező shadert futtat. Ezt azért csinálták, mert GPGPU-ra alkalmasabbak a skalár feldolgozók, így ebben a tekintetben jobban fog hasonlítani Fermire.

  Szóval én ezt kijavítanám a cikkben, mert ez egy durva hiba.

  Amúgy a többi újítás (amik igazából sokkal nagyobbak) szintén nagyon tuti és nagyon felkavarják végre az állóvizet ami a GPUs szolgáltatásokat illeti. Itt tényleg komoly integráció fog végbemenni a köv 2-3 évben.

Új hozzászólás Aktív témák