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

• #7 Meteorhead aktív tag

  Új Válasz 2013-07-03 17:06:07 #7

  Ú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

  Csak annyit akartam hozzáfűzni a cikk elejéhez (amit talán módosítani is kéne), hogy teljesen érthető, sőt preferált Intel compilernél a preferált 1-es vektor szélesség.

  Intelnek van messze a legbonyolultabb és legfejlettebb OpenCL compilere CPU-ra, ők ugyanis leimplementálták azt, amit az AMD nem tudott, és helyette architektúrát váltott. Az Intel compiler ugyanis azt csinálja, hogy akármilyen vektoros kódot is írtál, skalárműveletekre szedi szét az egész kernel kódot, és az AVX 4-8 sávján 4-8 kernel példány fut, tehát tökéletes a vektorfeldolgozók kihasználtsága. A nehézségek az elágazásoknál adódnak, főleg a kernel példányonként változó hosszúság ciklusoknál (ezt egy maszkolással oldják meg, és egyedül ilyen helyeken romlik a hatékonyság, ahol a maszkolt szálak is elvégzik a műveleteket, csak nem látni memóriában az eredményt). AMD-nek is hasonlót kellett volna implementálni a VLIW compilerükbe, de helyette szétszedték a vektorfeldolgozókat négy fürtre, így lett VLIW4-ből GCN (jó, persze GCN-ben másváltozások is vannak, de leginkább a szuperskalár feldolgozóról skalárra térés a legnagyobb váltás.

  Itt látszik, hogy mi a különbség az OpenCL-ben lekérdezhető "Native float vector width" és a "Preferred float vector width" között, mert nyílván ilyen compilerrel tök fölösleges vektorizálni (aki kapásból skalár kódra szedi szét), sőt inkább jobb tudni, hogy kár a gőzért.

  Eltérés a másik irányba is lehetséges amúgy, ahol a natív szélesség mondjuk 4, de a preferred 16. Ilyen lehet a char vektor, ahol egyes compilerek/architektúrák 4 byte-ra rendezik a regisztereket, és képesek tömöríteni őket.

  Szóval ezért 1 a preferred vector width Intel-nél.

• #41 Meteorhead aktív tag dezz #40

  Új Válasz 2013-07-12 11:01:36 #41

  Ú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 dezz #40 üzenetére

  A második cikk (ami inkább közelebb áll a technikai dolgokhoz) nemigazán hangsúlyozza ki a lényeget, de valahol ott van a sorok között. Megpróbálom saját szavakban, elmondani mi a különbség, és mi a mágia az Intel fordítóban.

  Ezek a cikkek nagyon szeretnek dobálózni a SIMD, MIMD, VLIW és hasonló szavakkal, csak azt felejtik el megemlíteni, hogy a HW mégis melyik szintjén érvényesek az állítások (mert már annyi szintje van, hogy egy gyakorlott róka is eltéved közöttük).

  HD6000 széria Radeonokból VLIW4-et használt. Ez azt jelenti, hogy mindegyik shaderprocesszor (SP) egy darab multiprocesszorban (CU) olyan kódot tudott futtatni, amiben egy órajel alatt (az egyszerűség kedvéért) 4 utasítást is végre tudott hajtani, amik különbözőek is lehettek akár. Ergo, ha olyan shader/kernel kódja volt az embernek, ami alapvetően skalár kód volt, akkor is egymás utáni műveleteket össze tudott pakolni egy VLIW instructionbe, és ez faján működik. Ha nagyon egymásra épülnek a számítások, az egyik eredménye kell a következőhöz, akkor a compiler meg volt lőve és nem tudott vele mit csinálni. Grafikai számításoknál viszont nevetségesen könnyű dolga volt, mert a 4x4 mátrixokat szorozása 4-es vektorokkal szétszedhető nagyon jól VLIW-re (de még SIMD-re is, ezen a szinten).

  VLIW tehát egy fajta MIMD, a feldolgozó szintjén. Azért hívják SIMD-nek a Cayman CU-t, mert ilyen VLIW feldolgozóból van benne 16db, de azok már halál ugyanazt csinálják egy órajelben, tehát ha ilyen messziről nézünk rá, akkor SIMD a CU. A problémát már meg is foglmaztuk (mint ahogy a második linkelt cikk is írja), hogy grafikára ez nagyon jól működik, de általános skalár kódra vért izzad a compiler, mire talál adatfüggetlenséget és feltölti a VLIW sávokat. Ezért sírtak emberek, hogy miért nem fut 4 kernel/shader példány egy SP-nek a 4 VLIW sávján? Azért mert buzi nehéz erre megírni a compilert. (GPU-n még olyan betegségek is vannak, hogy ott a vektor regiszter az vektor regiszter, és skalárváltozót nem szeret belerakni, de ez messzire vezet)

  Tehát AMD is folytatta NV példáját, és a művelet ütemezőt kirakta a kártyára. A compiler fellélegezhetett, cserébe olyan architektúrát rakott mögé, amire kellően könnyű ütemezni. VLIW nem lehet, mert futásidőben nem tudja a HW megcsinálni azt a mágiát, amin a compiler korábban offline tetszőlegesen sokáig gondolkodhatott. Mit csináltak? Szétszedték VLIW4-et 4 darab skalár fürtre. Ezek papíron más-más műveleteket is csinálhatnak, de a gyakorlatban ez ritkán, vagy szinte soha nem történik meg. Tehát 1 CU-ban van 4 skalár SIMD fürt, amik igazából ugyanazt a kódot futtatják, nagyjából lock-stepben.

  Ezzel szemben AVX önmagában egy SIMD feldolgozó, aminek ténylegesen ugyanazt kell csinálnia minden sávjában. AVX-szel megcsinálni azt, amit AMD compiler csinált VLIW-vel, hogy adatfüggetlenség alapján vektorosítja a skalár kódot szinte lehetetlen. Ezért csinálták azt, hogy 1-1 sávban 1-1 kernel példány fut. Ezt végig, tisztán azonos műveletekkel megcsinálni állati nehéz. AMD-nek sokkal könnyebb dolga lett volna VLIW-vel.

  AVX úgy tud MIMD-et, hogy a CU-k (ami egy x86 mag) csinálhat halál más dolgot, de maga az AVX az SIMD. Ezzel szemben HD6000 egy fajta MIMD belül, de kívülről SIMD, mert a CU-k ugyanazt a kódot futtatják. (Fermi CU-k tudnak más kódot futtatni, Tahiti-ben nem vagyok biztos, azt hiszem azok nem tudnak (cserébe tudnak elágazni, de most már zárom a sorokat, mert az idők végezetéig tudnék mesélni)

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