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

• #70 Abu85 HÁZIGAZDA #32839680 #69

  Új Válasz 2013-10-30 09:27:29 #70

  Ú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

  

  Abu85

  HÁZIGAZDA

  válasz #32839680 #69 üzenetére

  Nem a Larrabee-s mérnökök rakták össze a GCN-t. Az Eric Demers vezetésével született meg, csak ő elment a Qualcommhoz. Az ő helyére érkezett John Gustafson.
  Andrew Richards pedig szoftvermérnök. Ő csak azt kritizálta, hogy elképesztően nehéz lesz programozni a Larrabee-t. Sokkal nehezebben, mint egy hagyományos GPU-t. Ő már az elején mondta, hogy az x86 legyen kuka. A Larrabee ISA-ja legyen párhuzamosságra tervezve és elszeparáltan működjön a processzorrésztől. Mindig próbálkozott, hogy ezt megértesse az Intel vezetőségével, aztán belefáradt és otthagyta őket. Ebben persze szerepet játszott, hogy a HSA pont olyan, amit ő megálmodott, ezért ennek a tagja.
  A többi elégedetlenkedő mérnök más irányba menetelt. Michael Abrash például elment a Valve-hoz.

• #61 Abu85 HÁZIGAZDA LordX #55

  Új Válasz 2013-10-29 20:36:04 #61

  Ú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

  

  Abu85

  HÁZIGAZDA

  válasz LordX #55 üzenetére

  [link] - Vettek bizony hozzáértőket. Bár ez a ZiiLabs is egy agyonemulálós cucc. Meg is látszott a teljesítményén, vagy 100x lassabbak voltak mindenkinél, de futott az alkalmazás. Ez az emuláció valami fétish lehet az Intelnél szvsz.

  Egyébként korábban is megvoltak a világszinten zseni embereik ... Michael Abrash, Andrew Richards, Atman Binstock, Tom Forsyth, Mike Sartain, John Gustafson. Csak ők nem voltak annyira lelkesek a koncepció láttán, mint az Intel vezetősége. Ez nyilván egy olyan érdekellentét, ami után ők húzták a rövidebbet. A sluszpoén, hogy a MIC végül nem lett binárisan kompatibilis az x86-tal, tehát nem a mérnököknek lett igazuk.

• #46 Abu85 HÁZIGAZDA Fiery #33

  Új Válasz 2013-10-29 15:17:55 #46

  Ú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

  

  Abu85

  HÁZIGAZDA

  válasz Fiery #33 üzenetére

  Mindenképp módosítani kell az oprendszert, hogy bebootolja. De egyébként bármelyik modern GPU bebootol egy oprendszert, ha megcsinálod hozzá a szükséges vezérlőhidat a hardveres háttérnek és megírod rá a szoftvert. Itt inkább az a gond, hogy senki sem gondolkodik ilyenben. Önmagában ennek nincs is értelme, mert ha már raksz a rendszerbe kettő vagy négy procimagot (márpedig rakunk), akkor azon sokkal hatékonyabban megy bármilyen OS. A koprocesszorok - mert nyilván ezek a MIC/GCN-féle dolgok azok lesznek - a programfuttatásra vannak.
  Minden IGP-nek van ma is egy vISA szintű hozzáférési felülete, bár ezzel az Intel nem igazán törődik, mert kevés fejlesztőt érdekel. De a mostaniaknak is van, csak nem annyira jó, mint az AMD AGSL, vagy az NVIDIA NVAPI. Nyilván ilyenje lehet a MIC-nek is.

• #42 Abu85 HÁZIGAZDA Meteorhead #36

  Új Válasz 2013-10-29 14:57:06 #42

  Ú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

  

  Abu85

  HÁZIGAZDA

  válasz Meteorhead #36 üzenetére

  Egy GPU-t azért még mindig úgy terveznek, hogy az API-hoz illeszkedjen. Többek között van parancsprocesszoruk, amihez tartozik egy megfelelő driver. A MIC-nek ilyenje nincs, mindenképp szükséges egy olyan szoftveres réteg a hardver előtt, ami igazodik az adott API-hoz. Emulál egy GPU-t, erre nincs jobb szó. Viszont, hogy ne legyen azért vállalhatatlanul sok absztrakciós réteg, így érdemes olyan szoftvert írni, ami igazodik a hardverhez. Persze az egész felfogható egy túlhizlalt drivernek is, de kétségtelen, hogy nem szokványos a működés. Az egész egyébként elvi szinten hasonló lehet a SwiftShaderhez.

• #30 Abu85 HÁZIGAZDA Fiery #24

  Új Válasz 2013-10-29 12:49:42 #30

  Ú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

  

  Abu85

  HÁZIGAZDA

  válasz Fiery #24 üzenetére

  Most is lehet bármit programozni a fémen, de annyira irreális az ezzel járó extra munka, hogy nincs értelme egy bizonyos szint alá menni. Az OpenCLnek vannak hibái, de nagyjából az a szint, ami még vállalható erőforrás befektetését követeli, és az eredmény is nagyon gyors. Ez alatt már a nyerhető extra megkérdőjelezhető jelentőségű, főleg annak tudatában, hogy mennyi erőforrást kell még belefektetni.

  1) A Knights Landing magját kapják, tehát annak a speckóit kell figyelni.

  2) A MIC magok nem kompatibilisek a mai fő magokkal. Hiába az x86 akkor sincs bináris kompatibilitás a normál és a MIC magok között. Ennek az az oka, hogy az x86 memóriamodelljét módosítani kellett hogy a rendszer skálázódjon.

• #16 Abu85 HÁZIGAZDA ermisukrám #1

  Új Válasz 2013-10-29 10:34:34 #16

  Ú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

  

  Abu85

  HÁZIGAZDA

  válasz ermisukrám #1 üzenetére

  Nincs bináris kompatibilitás a MIC és a normál x86 magok között.

  (#4) gbors: Azt már ma is lehet írni csak eléggé komplex. HSA-val egyszerűbb lesz, de ott is le kell emulálni a szoftveres környezetet, ami túl időigényes. Ezért nem fog bele senki.

  (#13) Fiery: Az OpenCL a programozó oldaláról egyszerűbb, mint a vector intrinsics. Jóval kisebb erőforrás befektetésével kapsz ugyanolyan gyors kódot. Ennél egyszerűbb megoldás csak a C++AMP nagyon hatékony autóvektorizálója, de ezzel lassabb lesz a kód, vagy komplexebb dolgokat nem lehet megcsinálni vele. Persze sokaknak elfogadható lesz ez a kompromisszum.

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