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

• #110 Abu85 HÁZIGAZDA julius666 #107

  Új Válasz 2012-11-08 16:00:07 #110

  Ú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 julius666 #107 üzenetére

  A HSA az nem egy extra réteg lesz. Ma az OpenCL-t minden gyártó úgy támogatja, hogy a GPU ISA előtt van egy vISA. Mindenkinek más. Ez ezért kell, mert a GPU lényege a skálázás. Ezt már az ISA és a memóriamodell szintjén beletervezik. Ergo 3-4-5 évente mindenki lecseréli a GPU ISA-t és memóriamodellt egy újra, hogy jobb legyen a skálázás. Erre van a vISA a GPU-k előtt. A HSA ötlete, hogy ne legyen minden gyártónak külön vISA-ja, hanem mindenki használjon egy közöst, ami a HSAIL. Ezzel erre a vISA-ra is lehetne direkten alkalmazást írni, és akkor teljesen kizárható a driver stb. Akik beléptek ebbe az alapítványba azok a cégek eldöntötték, hogy a jövőben közös HSAIL-t használják majd a saját vISA-juk helyett. Ez jelentősen egyszerűsíti majd a munkát, és az alkalmazás teljesítményének portolhatóságát. Vannak már webinarik is egy ideje. A fejlesztők a HSA alapítvány oldalán jelentkezhetnek erre. A HSA Bolttal már mutatták, hogy majdnem el lehet érni az OpenCL-C sebességet, és eközben rövidebb a kód, mintha C-ben írnád párhuzamosítás nélkül. Ezért nőtt háromszorosára az érdeklődés a HSA iránt fél év alatt. A gyártók látják a fizika problémáit, míg a programozók is lassan rájönnek, hogy itt a gyártók most tényleg nem viccelnek, és valóban nem tudják növelni a teljesítményt a megszokott úton. Nyilván a programozók miatt történik ez a HSA, hogy egyszerűbb legyen a dolguk. Sosem lesz közös fizikai ISA a GPU-knál, mert nem fognak működni a rendszerek, de a vISA-t közösre lehet rakni.

  A Windows 8-ban már per engine reset van. Ha lefagy az alkalmazás, akkor nem omlik össze az OS, hanem újraindul az engine. Ezt az MS szándékosan fejlesztette ilyenre a WDDM 1.2-ben, nyilván ők is átgondolták, hogy C++ AMP mellett ez gond lenne, de így tulajdonképpen akkor sem lesz baja az OS-nek, ha egy GPU-s alkalmazás áll le. Ettől persze bármikor lefagyhat az OS, de ennek lesz nem nagyobb az esélye GPU-s alkalmazás mellett.

• #109 ddekany veterán agressiv #108

  Új Válasz 2012-11-08 15:44:39 #109

  Ú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

  

  ddekany

  veterán

  válasz agressiv #108 üzenetére

  Amennyiben desktopon az olyan feladatok nem számítanak... Persze most is 99%-ban elvagyunk azzal ami van, mert legfőbb alkalmazásokat (videó lejátszás és 3D) lefedték célhardverrel. Kérdés, hogy mikor már szabadon programozhatóbb lesz a GPU-jellegű vagy csak nagyon-sok-magos vas, megjelenik-e pár új alkalmazás ami széles körben elterjed. Pl. lehet, hogy 15 év múlva természetesnek fogjuk venni, hogy a videó-telefonálásnál ki lehet üttetni a hátteret, vagy hogy szóval és mozdulatokkal megbízhatóan lehet távvezérelni a gépet, vagy hogy sokkal jobb a játékokban a fizika.

• #108 agressiv addikt julius666 #107

  Új Válasz 2012-11-07 18:44:38 #108

  Ú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

  

  agressiv

  addikt

  válasz julius666 #107 üzenetére

  És akkor nem is lehet a "hétköznapi" alkalmazások legnagyobb részénél a grafikus felületen kívül mit kidobni GPU-ra.

  Vagyis baromság az egész?

• #107 julius666 addikt Zeratul #105

  Új Válasz 2012-11-07 00:52:08 #107

  Ú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

  

  julius666

  addikt

  válasz Zeratul #105 üzenetére

  a HSA ép ezt fogja kiküszöbölni, hogy ne kelljen minden GPU fajtára kézzel optimalizálni, hanem 1x megírják és utána csak lefordul és kész.

  Az OpenCL-ben már most is is 1× megírják és kész, fut mindenen. Ha meg arra gondolsz, hogy optimalizálni kell a kódot és ezért külön architektúrákra mást írni, ezen a téren a HSA kétlem hogy sok előnyt hozna, ugyanúgy különböző architektúrákról beszélünk, csak lesz valami elvárt minimum illetve föléjük húzva egy viszonylag alacsony szintű közös réteg.

  A GPGPU azért nem terjed olyan baromi gyorsan mert elég macerás (ergo drága) rá kódot írni, a processzor és a GPU közti szinkronizálás, vagy akár GPU-n belül annyira lassú és vacakolós, hogy jóformán azalatt a processzor sokszor elvégezné maga a melót (cserébe viszont az összfogyasztást esélyes hogy alaposan megdobja a dolgozó GPU), illetve a driverek sem mindig százasok. Ha a CPU-n van valami gebasz az alkalmazásban akkor max az alkalmazás zakózik egyet, ha a GPU-n akkor esélyes hogy akár az egész oprendszer (kékhalál). Debugolni meg szintén nem a legjobb GPU-n.

  És akkor nem is lehet a "hétköznapi" alkalmazások legnagyobb részénél a grafikus felületen kívül mit kidobni GPU-ra.

• #106 ddekany veterán Pikari #101

  Új Válasz 2012-11-06 19:10:37 #106

  Ú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

  

  ddekany

  veterán

  válasz Pikari #101 üzenetére

  "a nagy igényű programoknak pedig olyan 90%-a képes kihasználni a több processzormagot"

  Mit értesz nagy igényű alatt? Ami szerveroldali (pl. egy adatbázis kezelő), már csak azért is ezer éve kihasználja, mert egyszerre több kliens nyúzza. Viszont itt kliens oldalon futó cuccoknál akarják kihasználni a sok magot (mobil telefon). Ami ott jól párhuzamosítható, az azt gondolnám jellemzően olyan feladat, ami egy GPGPU-nak is fekszik. Tehát most vagy találni akarnak még más több szálra bontható feladatokat, pont azokat a feladatokat akarják pár tucat teljes értékű x86 maggal ledarálni, még több tucat korlátozott tudású CU (vagy ahogy épp hívják) helyett. Csak akkor nem mernék rá sokban fogadni, hogy nem sülnek fel ezzel Intelék (mert tudnak ők olyat is...) az AMD specializáltabb megoldásával szemben.

  "a gpgpu révén nyújtható gyorsítást egy rövid wikipedia oldalon felsorolható mennyiségű program támogatja"

  Most még...

• #105 Zeratul addikt agressiv #104

  Új Válasz 2012-11-06 19:04:58 #105

  Ú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

  

  Zeratul

  addikt

  válasz agressiv #104 üzenetére

  Általános fejlesztő környezet hiányában ne csodálkozz rajta, a HSA ép ezt fogja kiküszöbölni, hogy ne kelljen minden GPU fajtára kézzel optimalizálni, hanem 1x megírják és utána csak lefordul és kész.

• #104 agressiv addikt Zeratul #103

  Új Válasz 2012-11-06 15:10:41 #104

  Ú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

  

  agressiv

  addikt

  válasz Zeratul #103 üzenetére

  De valamiért a gyakorlatban nem nagyon látni, ez a baj.

• #103 Zeratul addikt Pikari #101

  Új Válasz 2012-11-06 14:52:25 #103

  Ú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

  

  Zeratul

  addikt

  válasz Pikari #101 üzenetére

  Gpgpu épp a masszívan párhuzamos feladatok esetén brillíroz.

• #102 CYBERIA őstag Pikari #101

  Új Válasz 2012-11-06 14:09:02 #102

  Ú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

  

  CYBERIA

  őstag

  válasz Pikari #101 üzenetére

  Tévedsz.

• #101 Pikari addikt ddekany #97

  Új Válasz 2012-11-06 13:03:24 #101

  Ú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

  

  Pikari

  addikt

  válasz ddekany #97 üzenetére

  én nemtom hogy mire gondolsz, de kb 20 évre visszamenőleg az összes program threadelt, a nagy igényű programoknak pedig olyan 90%-a képes kihasználni a több processzormagot. a gpgpu révén nyújtható gyorsítást egy rövid wikipedia oldalon felsorolható mennyiségű program támogatja, ami az összes programok kb 1 tízezreléke SE. az asszimetrikus MP egy halott koncepció, sosem fog felfutni, ez egy téveszme, amit a laikusokkal szopatnak fel.

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