2. Fórumok
  3. Processzorok, tuning
  4. Elérhető az Intel OpenCL drivere
Keresés

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

  • #36 dezz nagyúr P.H. #32
    Új Válasz #36
    Ú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

    dezz

    nagyúr

    válasz P.H. #32 üzenetére

    Nem tudom, mi lehetett ott a gond, de én futtattam pár OpenCL kódot, amik 100%-on pörgették a GPU-t, mégsem tapasztaltam ilyen komoly belassulást (csak kicsit) a GUI-kezelésben. Közben tudtam mozgatni az ablakokat, stb.

  • #34 Abu85 HÁZIGAZDA P.H. #32
    Új Válasz #34
    Ú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 P.H. #32 üzenetére

    Ahogy így ezt leírtad, egyet értek vele.
    Annyit tennék hozzá az NV-s részhez, hogy a CUDA még a C++ AMP-nél is nagyobb prioritás marad. Lehet, hogy nem szarnak majd annyira rá, mint az OpenCL-re, de az integrációnál az ARM mag a legacy programok szempontjából hendikep, lehet, hogy egy csomó progit átfordítanak, de mindre nincs lehetőség. A CUDA jó (marketing)eszköz lehet a hendikepre való kontrázásra. :) Amolyan kiütjük vele a negatívumokat dolog ez. Éppen ezért a CUDA mindennél előbbre van az NV-nél. Ha meg lehet győzni valakit, arról, hogy a CUDA-ra csinálják a progit, akkor kíméletlenül félresöprik a független megoldásokat.

    (#33) P.H.: Köszi, hogy ezt leírtad, sokkal világosabb lett a dolog. :R

  • #31 Abu85 HÁZIGAZDA P.H. #30
    Új Válasz #31
    Ú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 P.H. #30 üzenetére

    Azt én sem teszem. :) Ennek normálisan úgy kell működnie, hogy lehessen a gyártókat mixelni, és a specifikációk ezt lehetővé is teszik. A programban és a driverekben ejtett hibák azok amikre nincs előre gyógyír. Akármilyen diktátor az MS ez rész kivédhetetlen. Minimálisra csökkenthető a lehetőség, de kivédeni nem lehet.

    Az MS dettó ugyanilyen közvetlen GPU elérésű Silverlight 5-öt csinál. Biztonsági szempontól semmiben sem fog különbözni a WebGL-től. Jon Peddie írt erről egy nagyon jó cikket. [link] Világos, hogy foglalkozni kell a kérdéssel, de ha nem terjesztjük ki a grafikus drivereket a webre, akkor sosem lesz GPU-s gyorsítás a böngészőben. Nyilván ezek a felületek potenciális biztonsági kockázatok, és valamit kell kidolgozni, hogy ne legyenek azok, de az ActiveX is egy átjáróház például, és boldogan él a felület, pedig a GPU-hoz ennek köze sincs. :) A másik, hogy ha elvegyük a közvetlen GPU elérést, akkor nem kicsit fog a rendszer lassulni. Persze ez is egy opció.

    A gyártók mixelésének általános problémája szerintem lassan megoldja saját magát. Ha heterogén irányba fejlődünk (márpedig abba fejlődünk), akkor a fejlesztőknek közös címtér és teljesen koherens memória kell a CPU-nak és a GPU-nak. Ami most van az amolyan léptünk egy lépcsőt, de az emelet még messze van. Ha véghezviszik a terveket, akkor a dGPU-k problémája az lesz, hogy a rendszermemória túl messze van, és ez akadályozza a hatékonyságot. Erről beszélt Carmack az idei keynote-ban, hogy például a megatextúrázásnak nagyon nem kedvező a GPU dedikált memóriája, és hogy nincs messze az az idő, amikor az IGP-k elegendőek lesznek a programok futtatására. Itt ugye figyelembe kell venni a dedikált memória hiányában keletkező előnyöket, ami egy dGPU-nak hátrány lesz. Elérhetik a dGPU-k is a rendszermemóriát, de sokkal lassabban, mint egy IGP.
    A másik kérdés, ami bennem felmerült, hogy az rendben van, hogy az AMD GCN-es dGPU-k támogatják majd az x86 virtuális memóriát a CPU pointereken keresztül, de az NV-nek van-e erre licence? Ez bizonytalansági tényező, ami esetlegesen probléma lehet a mixelésnél. Aztán ott az OS kérdése. Consumer szinten ez is egy óriási probléma, hiszen megfelelő OS hiányában nem egyszerű megoldani a GPU virtuális memória kezelését. A GCN-ben erre már van egy PRT eljárás, ami értékelhető, de véleményem szerint nem lesz alapvető része a nextgen grafikus API-knak, maximum kiterjesztés szintjén kerül beléjük.

    A bonyolultságból eredően én azt látom, hogy a gyártók mixelése (bár technikailag lehetséges lesz) alapvetően meg fog szűnni, már abból a szempontból, hogy gépvásárlásnál nem akarsz magadnak rosszat a terméktámogatás és a feature lista tekintetében. Sőt a VGA-k jelentősége pár éven belül a hangkártyák szintjére esik. Ezzel megváltozhat a termékek jelentősége is. Azoknak jó lesz, akik professzionális számításokon dolgoznak, de mondjuk egy átlag júzernek a játékban már mást fog jelenteni a dGPU, mint amit jelent most. A rendszermemória távolsága például a post process effekteknél nem jelent problémát, így a játékok esetében úgy gondolom, hogy az extrák kerülnek előtérbe a dGPU-k esetében, pont ahogy a hangkariknál az EAX szintek támogatása. Ez még képlékeny terület, de majd úgy 2013-2014 felé, amikor megérkeznek, az igazán jól programozható APU-k, akkor látni fogjuk, hogy milyen területek maradnak meg a dGPU-nak.

  • #21 Abu85 HÁZIGAZDA P.H. #16
    Új Válasz #21
    Ú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 P.H. #16 üzenetére

    A Khronos is szoros kapcsolatban áll a gyártókkal. Ugyanúgy jól specifikált felület az OpenCL is, és szimplán elméletben az OpenCL is akármilyen hardveren és hardverkombináción fut. Ebből a szempontból a C++ AMP-től nem különbözik.
    A gyártók mixelésével a probléma nem a specifikációkban van jelen, hanem az emberi hibában. Ha megnézel most egy DirectX-re írt alkalmazást, akkor láthatod, hogy simán előfordul, ha a grafikus driver hibázik benne. Ez benne van a pakliban, mert ember írja a programot és a drivert is ... megoldás, hogy javítják, és mindenki örül. Ez ugyanúgy elő fog fordulni OpenCL és C++AMP alatt is. A probléma itt azért súlyosabb, mert mixelt konfigurációban két driver is lehet a ludas, ami a hibakeresést megnehezíti. Előfordulhat olyan, hogy együtt kell dolgoznia a két konkurens gyártónak a probléma javításán. Ebből a szempontból az azonos gyártóra épített gép előnyösebb lehet, mert házon belül, sokkal gyorsabban lehet reagálni egy hibára.
    Ez MS ezzel ugyanúgy nem tud kezdeni semmit, ahogy a Khronos sem. Hibák voltak és lesznek a programokban. Jönni fog a javítás, csak az nem mindegy, hogy mikor. Éppen ezért, ha a gyártók továbbra is szeretnék megtartani a mixelést (amit egyébként nyilván egyikük sem akar :N ) szükséges valamilyen szintű együttműködés a driverek szempontjából. Ha mást nem a hibák keresése esetében össze kell dugni a buksijuk.

    A DirectCompute véleményem szerint sosem volt az OpenCL valós ellenfele. Egy jól integrált felület a DirectX-be, ami a játékok és a DirectX-re írt 3D-s programok esetében valóban kiválóan használható, de semmi több. A C++ AMP a működésben az OpenCL-t másolja. Ugyanúgy kell hozzá CPU-dirver és GPU-driver, szimplán elméletben az akármilyen hardveren és hardverkombináción fut, ahogy az OpenCL is, de a programozói vagy driveres hibát ez sem tudja kivédeni.

    (#19) bitblueduck: Természetes, hogy követelmények lesznek, de a DirectX-ben is vannak, ráadásul pokolian szigorúak, és mégis van olyan program, amihez új grafikus driver kell a megfelelő futtatáshoz. Gond egy szál se, a C++ AMP-hez is jöhetnek majd friss driverek, amik javítják a hibákat, csak a DirectX-szel ellentétben itt konfigtól függően két gyártón is állhat a vásár, és ez jelenti a nehézséget.

  • #17 siriq őstag P.H. #16
    Új Válasz #17
    Ú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

    siriq

    őstag

    válasz P.H. #16 üzenetére

    Pl. azt, hogy akármilyen hardveren és hardverkombináción fut?
    Ezt mar irtam en is regebben ezert szimpatikusabb nekem ez a megoldas.

  • #14 Abu85 HÁZIGAZDA P.H. #11
    Új Válasz #14
    Ú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 P.H. #11 üzenetére

    Ilyen az OpenCL is. Nem ezzel van a baj, hanem a fejlesztői trehánysággal (ideértve a programírókat és természetesen a driverírókat is). Erre az MS-nek eddig sem volt hatásköre. Ez a dolog kivédhetetlen most is. Láthatod a VGA-drivereket. A probléma a heterogén rendszereknél azért súlyosabb, mert egy-egy hiba javítása nem biztos, hogy megoldható majd házon belül, hiszen a program futtatása két gyártó driverén is múlhat.

  • #10 Abu85 HÁZIGAZDA P.H. #9
    Új Válasz #10
    Ú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 P.H. #9 üzenetére

    Elméletben az OpenCL-ben sem kellene ennek problémának lennie, de sajnos mégis az. Ez szimplán az adott program hibája, de ettől még nem fut jól a program.
    A WHQL nem teszteli a konkurens driverek együttműködését. Azt teszteli, hogy a Windows folyamatokkal milyen a stabilitás.
    Bármilyen platformmal megyünk a heterogén számítások irányába a gyártók mixelés állandó probléma lesz. Messze nem megoldhatatlan, de hibaforrás.

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

Hirdetés