Hirdetés

  2. Fórumok
  3. Videokártyák
  4. Saját grafikus API-t fejleszt az Intel?
Keresés

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

  • #70 Abu85 HÁZIGAZDA #32839680 #69
    Új Válasz #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 #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. :D

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