- Motorola G86 - majdnem Edge
- iPhone topik
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Samsung Galaxy Z Fold5 - toldozás-foldozás
- Honor 200 Pro - mobilportré
- Nothing Phone (2) - több, mint elsőre látszik
- Android alkalmazások - szoftver kibeszélő topik
- Motorola Edge 50 Neo - az egyensúly gyengesége
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Fotók, videók mobillal
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
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.
-
Abu85
HÁZIGAZDA
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.
-
Abu85
HÁZIGAZDA
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
) 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.
-
Abu85
HÁZIGAZDA
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.
-
Abu85
HÁZIGAZDA
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. -
Abu85
HÁZIGAZDA
Persze, annyi opencl drivert telepítesz amennyit akarsz. A kérdés, hogy ezek a program futtatásánál hogyan működnek együtt. Elméletben úgy van kialakítva a felület, hogy nem lehet gond, de a heterogén módon történő futtatásra csak azonos gyártótól származó driverek esetében van garancia. Ugyanígy fog működni a C++ AMP is.
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.
) 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.
Új hozzászólás Aktív témák
Hirdetés
- Telefon felvásárlás!! Huawei P20 Lite/Huawei P20/Huawei P30 Lite/Huawei P30/Huawei P30 Pro
- Azonnali készpénzes Microsoft XBOX Series S és Series X felvásárlás személyesen/csomagküldéssel
- Bomba ár! Lenovo ThinkPad T450s - i5-5GEN I 12GB I 500GB SSD I 14" HD+ I Cam I W10 I Garancia!
- Azonnali készpénzes Intel i3 i5 i7 i9 12/13/14 gen processzor felvásárlás személyesen / csomagküldés
- Telefon felvásárlás!! iPhone 15/iPhone 15 Plus/iPhone 15 Pro/iPhone 15 Pro Max
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest