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

• #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