Hirdetés

Hirdetés

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

  • Sanya

    nagyúr

    egy működő programot azért megnéznék.

    másik: egy intel-nvidia rendszer esetében akkor fel kell lökni az intel drivert, illetve a legújabb 2.80-as nvidia drivert az opencl progik futtatásához?

    A bortól bolondokat gondol az ember, DE A PÁLINKÁTÓL MEG IS CSINÁLJA!!!

  • Abu85

    HÁZIGAZDA

    válasz Sanya #1 üzenetére

    Ha heterogén módban akarod futtatni a progit, akkor mindkét driverre szükség van, de semmi garancia arra, hogy jól fognak működni együtt.

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • -Melkor-

    csendes tag

    válasz Abu85 #2 üzenetére

    Az oké, hogy nincs rá garancia, de valaki próbálta már, hogy működnek-e együtt? Ugyanez érdekelne AMD-nVidia, Intel-AMD párosítással is.

  • RyanGiggs

    őstag

    válasz Abu85 #2 üzenetére

    Mint az előttem szólokat, engem is érdekelne, hogy pl. működnek együtt?! :F
    Amúgy ha heterogén módban szeretném hogy működjön, akkor
    mindenféle képen fel kell telepítenem mind a két drivert?
    Pl.: ha van egy AMD HD5850-es vgám, és egy "régi" Q9550-es procim?

  • Abu85

    HÁZIGAZDA

    válasz -Melkor- #3 üzenetére

    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.

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz RyanGiggs #4 üzenetére

    Az AMD drivere tartalmaz CPU-drivert is, csak ott meg nincs garancia arra, hogy az Intel procival az a driver hibátlan.

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • vinibali

    őstag

    ha kicsit nagyobb lenne az AMD gyártókapacitása és lenne rendesen marketingük... ezzel a rendszerrel eléggé nagyon ütnének... na mintha így nem :)

    BIOS/UEFI írás, helyreállítás, törlés, mentés! https://www.bvinarz.org/bios-iras/

  • MZperX75

    addikt

    válasz vinibali #7 üzenetére

    "ha kicsit nagyobb lenne az AMD gyártókapacitása és lenne rendesen marketingük... ezzel a rendszerrel eléggé nagyon ütnének"
    Azt Viszont az Intel biztosan nem engedi ,már a nagyobb gyártosort.
    PL: E-350-el szerelt nettopot szerettem volna venni 10-11",szerinted melyik gyártó merte beválalni?Nem sokat látni belölle,persze biztos hogy van,de én még nem láttam ,csak 13"-15"ban. persze olyan áron,hogy inkább Intel atomot veszem meg(nem veszem csak mondom)
    Intel szépen fizet ,vagy lefizet,,bekebelez vagy tönkretesz,ha a másik gyártót segíted,vagy mersz az Intel piaca felé nézni.
    Háború van.
    Mintha már lett volna ilyen,
    pert nyert egyszer -kétszer AMD ,de a hajára kenhette.Az NV-nak is be lett tömve a kis szája.
    Azóta nem változott szinte semmi.
    Olyannyira befolyásolja az Intel a piacot,hogy bele sem merek gondolni.
    Jó ez így nekünk?
    OFF
    (kit érdekelnek a kis emberek?,Bank kölcsön ad,(Frank:272Ftaztán ,anyád házát is elveszíted) Rendesen etetve vagyunk ezen a bolygón......
    Csak azt mondja meg nekem valaki,miért kell minden céhgnek ultra-extra nyereséget termelnie?
    Ez olyan mintha minden hónapban egy kicsivel többet kellene ennem,mert éhen halok,ha 15%-kal nem eszem többet./persze fejlődni kell!
    "jöjjön már az a szent*Meteor*" sokan vagyunk!" :DDD
    OFF

    [ Szerkesztve ]

  • P.H.

    senior tag

    válasz Abu85 #5 üzenetére

    "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."

    A C++ AMP is? Az MS mint azonos gyártó fogja csinálni a köztes köztesrétegeket a CPU-hoz és a GPU-hoz, vagy hogy kell ezt érteni?
    Az is rendben lenne, hogy a gyártók külön készítik a termékeikhez a köztesréteget, de ha ezek együttműködését sem tudja az MS koordinálni, akkor ott valami nem stimmel. A WHQL-mérce ennyire alacsony lesz?

    [ Szerkesztve ]

    Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙

  • 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.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • P.H.

    senior tag

    válasz Abu85 #10 üzenetére

    Feltételeztem, hogy a C++ AMP legalább annyira gyártófüggetlen lesz, mint a DirectX, kiegészülve azzal, hogy akármin (CPU-n, GPU-n, vegyesen) is futtatható, tehát elvileg az összes, gyártók által biztosított felületnek ugyanazt kell tudnia; így viszont megoldható az együttműködésük is.

    Ezeket a dolgokat legalább normálisan meg tudta oldani eddig az MS. Ha ezt nem fogja, akkor semmi értelme nem lesz az egésznek. :(

    [ Szerkesztve ]

    Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙

  • vinibali

    őstag

    válasz MZperX75 #8 üzenetére

    tudom... én még karácsony után mentem be az europarkos saturnba. sztem hány AMD-s gépbe botlottam? hát szinte csak azzal volt tele minden :) tényleg undorító amit az Intel csinál... volt pont egy ilyen "Michelisz Norbis" videó a youtubeon 3.43-tól:)

    [ Szerkesztve ]

    BIOS/UEFI írás, helyreállítás, törlés, mentés! https://www.bvinarz.org/bios-iras/

  • Hurráizé... ...hol a @%&!ba van az IGP-támogatás?

    A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.

  • 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.

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • P.H.

    senior tag

    válasz Abu85 #14 üzenetére

    Ezek szerint félreértettél: a gyártóknak nem szükséges egymás termékein tesztelni a saját megoldásukat, viszont a C++ AMP egy szoftverfejlesztő cég ötlete, ami kapcsolatban áll az Intel-el, az AMD-vel, az NV-vel, az ARM-mal és még számos más érintett gyártóval. Az ő ötlete, elvileg az OpenCL mellé, tehát annál valamivel többet vagy valamiben mást kell nyújtania. DirectX vs OpenGL esetben sikerült, így maga mellé állította a játékfejlesztőket.

    A saját DirectCompute mellett miért vagy hogyan lehet életképes egy C++ AMP is, ha nem tudna valami pluszt nyújtani?
    Pl. azt, hogy akármilyen hardveren és hardverkombináción fut?

    Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙

  • 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.

    Meg mindig nincs 1000 oras BF3 nev, kozben mar masok is erdeklodnek utana... Mar bevallottan nincs 1000 ora neki... Varjunk Dec 31-ig a Mantle-a.

  • Puma K

    veterán

    válasz Fooler89 #15 üzenetére

    Miért szereted az AMD-t?

    "Cuccok: csattogós lepke és tiki-taki" └[ʘヘʘ]┘

  • bitblueduck

    senior tag

    válasz Abu85 #14 üzenetére

    Az MS azért szokott kommunikálni, meg követelményeket támasztani a gyártók felé. C++ AMP-re valami hasonlót várnék, mint amilyen DX.
    Hírhez: Inteltől nem is vártam mást. Minek is kellene támogatni a GPU-kat... jah hogy nekik nincs is a klasszikus értelemben olyan, ami használható lenne :DDD

    An open mind is like a fortress with its gates unbarred and unguarded.

  • oPalRx7

    tag

    válasz Puma K #18 üzenetére

    kevésbé "zárt" és folytja el a lehetőségét a termékeinek más termékekkel való használatától?
    nem támogatja, de legalább el se tiltja (pl radeon+physX, most opencl esetén, és régebbi termékek támogatásánál)

  • 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.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Fooler89

    őstag

    válasz Puma K #18 üzenetére

    Mert az amd drivere támogatja a heterogén futattás. Nem fog senkit se ráerőltetni semmire. Nagy általánosságba elmondható az amdről, hogy amire lehetőség van azt ő megadja. Tudom, hogy a heterogén módnak mik a hátulütői de akkor is foglalkozik vele.
    Nem irányítani akarja a piacot hanem megfelelni neki.

    Plusz azért is mert mostanság elkezdett a linuxos driverekkel foglalkozni ami megint csak pozitív.

    [ Szerkesztve ]

  • wad

    tag

    Az Nvidiának nincs 1.1-es OpenCl támogatása. Csak egy beta driver, ami sajnos viccnek is rossz.

  • Abu85

    HÁZIGAZDA

    válasz wad #23 üzenetére

    280.26 WHQL - ez már ocl 1.1-es. Valóban nem a legjobb, de legalább elindultak ezen az úton.

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • wad

    tag

    válasz Abu85 #24 üzenetére

    "July – NVIDIA releases updated R280 drivers that incorporate OpenCL v1.1 support previously available to registered developers"

    El sem hiszem, röpke egy év kellett hozzá. A kommentek alapján viszont van némi sebesség degradáció a developer és a release drivereknél is. Majd ellenőrzöm, ha éppen nem fagyok :).

    Szerk: bocs az offtopicért, most látom csak a hírt, amit írtál.

    [ Szerkesztve ]

  • Yany

    addikt

    van valami jó, megbízható opencl benchmark?

    Építs kötélhidat  -  https://u3d.as/3078

  • vanhalen

    senior tag

    Érdekelne, ha eredetileg az OpenCL a grafikus chipekben lévő shader egységek (nem csupán 3D hanem) általános célú programokban történő munkára fogásának van/volt hivatott a segge alá alapot adni, hogy a CPU terhelése csökkenjen és/vagy a CPU párhuzamosan más/több feladatot láthasson el, miközben a shader egységek (ugyanúgy, vagy gyorsabban) elvégzik az adott feladatokat, levéve ezzel a CPU "válláról" egy adag terhet, akkor hogy jött képbe a CPU OpenCL támogatásának szükségessége/igénye?

    Valaki kifejthetné, mert baromira nem vágom CPU mikor jött a képbe és mennyiben segít a grafikus chipnek OpenCL szinten. Az Intel "megoldását" látva pedig új kérdés merült fel bennem: OpenCL mit nyújt, nyújt e egyáltalán "csak" CPU-s oldalon? Komolyan totál homály.. NEM ÉR RÖHÖGNI! :D

    [ Szerkesztve ]

  • wad

    tag

    válasz vanhalen #27 üzenetére

    Eddig, ha valaki CPU-n és GPU-n egyaránt futtatható szoftvert akart produkálni, akkor ugyanazt az algoritmus két fajta implementációban (OpenCL és pl. C++) kellett megírnia és fenntartania. (Ez nem feltétlenül járt a kód megkétszereződésével, köszönhetően a nyelvek szintaktikai közel azonosságának, de mindenképpen többletmunkát és bonyolultabb kódot eredményezett.) A CPU-s drivernek köszönhetően egy az egyben ugyanaz a kód vált futtathatóvá mindkét platformon.

    Alapvetően két oka lehet annak, hogy miért akar valaki GPU helyett, vagy mellett CPU-n futtatni:
    1. Szélesebb körű kompatibilitás: azokon a gépeken is eldöcög a szoftver, amelyekben nincs OpenCL-t támogató GPU.
    2. Nem minden algoritmust lehet optimálisan párhuzamosítani GPU architektúrára. Bizonyos esetekben az ideális 50-100-szoros sebességbeli különbség helyett nagyságrendileg "csak" a CPU számítási teljesíményét kapjuk vissza. Ilyenkor számottevő gyorsulást eredményezhet, ha az algoritmusunkat a GPU mellett párhuzamosan a CPU-n is futtatjuk.

    Kiegészítés: Még nem olvastam erre vonatkozó tesztet, és magam sem próbáltam, de az OpenCL-es kód CPU-n elvileg lassabb futást eredményez, mintha ugyanazon algoritmus C nyelvű implementációját hagyományos módon (pl. OpenMP) párhuzamosítottuk volna. Valamennyi sebességet tehát áldozni kell az univerzális kódért.

    [ Szerkesztve ]

  • vanhalen

    senior tag

    válasz wad #28 üzenetére

    Köszönöm a választ, így már sokkal jobb.
    Ha jól értem, akkor lényegében a (z elsődleges) cél az OpenCL-ben megírt alkalmazások kompatibilitásának megőrzése hiányos, vagy nem kielégítő hardverkörnyezetre, hogy legvégső esetben, ha teljesítmény veszteséggel is, de futtathatóak legyenek a szóbanforgó programok? (Pl. ha csak CPU áll rendelkezésre OpenCL-re képtelen GPU/IGP-vel)

    [ Szerkesztve ]

  • P.H.

    senior tag

    válasz Abu85 #21 üzenetére

    Tisztában vagyok azzal, hogy a Khronos milyen problémákba ütközik ezen a téren, de ebből nem tenném azt az általánosítást, hogy ennek így kell lennie, és kész.

    Az MS már bevitt egy nagy pofont a Khronos által felügyelt WebGL-nek, ami miatt aztán a Khronos-nak magyarázkodnia kellett, mondván, hogy a GPU-k mai fejlettségi szintje és azok driveres támogatása igencsak sok kívánnivalót hagy maga után. Nyilván ezt így, ebben a formában nagy tömegek kezébe adni legalábbis nagy körültekintéssel kell, mivel (ahogy írtam is) és a magyarázatból is kiderül, ma alapvetően multitask-képtelen és biztonságilag elhanyagolt GPU-megoldásokról van szó. Ezt te leütötted azzal, hogy persze, az MS támadja, mert neki csak később lesz ilyen. De nem, az MS sem tud sárból várat építeni, nekik ugyanúgy szükséges az, hogy a gyártók oldják meg ezeket a problémákat, még ha ezek ma tranzisztorpocsékolásnak, felesleges teljesítménycsökkentő feature-öknek is tűnnek, ezt meg kell lépni.

    A Khronos lehet gyengekezű, ráhagyhatja a gyártókra az OpenCL-nél is az ilyen-olyan megvalósítást, de nyilván nem ez a széles tömegekhez vezető kulcs.

    Ugyanez a helyzet a C++ AMP-nál is: ha nem állít hozzá egy elég erőskezű diktátor megfelelő követelményrendszert, akkor sosem fog hétköznapi, átjártható, normális felületté fejlődni. Ha viszont állít normális feltételeket, akkor semmi akadálya a több gyártó által készített megoldások együttműködésének.
    A DirectCompute-t be lehet ágyazni a DirectX-be, ami eléggé izolált, kockázatmentes és a felhasználó által jól kézben tartott módja a GPU-kihasználásnak (az user tudja, mit indít, mikor indít, az milyen adatokkal dolgozik, nem futtat több játékot egyszerre, stb.), de ennél az általános, hétköznapi GPU-gyorsításhoz több kell; mutatja ezt, hogy te sem veszed "komolyan".

    [ Szerkesztve ]

    Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙

  • 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.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • P.H.

    senior tag

    válasz Abu85 #31 üzenetére

    Közben láttam, meg is jelent egy témábavágó cikk.

    Úgy tűnik, két dologban nem fogunk egyetérteni: sem abban, hogy egységes felület kialakítását főleg emberi hibák akadályozzák, sem abban, hogy ha valami ellen érveket hoznak fel, akkor jó válasz rá - eltekintve a szokásosan közrejátszó martketingtól -, hogy valóban, de a kritizáló sem tud más területen jobbat felmutatni. Szerencsére az fel sem merül, hogy az ActiveX hiányosságait hardveren vagy driveresen javítsák :), a WebGL-lel felhozott általános GPU-problémákra pedig hardveres sémák már léteznek, csak alkalmazni kell őket előbb-utóbb.

    A védelem IGP-szinten közel triviálisan megoldható azzal, hogy a lapozást bevezetik az IGP-re is, ezt az akadályt jól vették a single->multi core áttéréskor is, az IGP is csak egy x+1. ágens a rendszerben. Amúgy sem nézi sokáig jó szemmel a világ, hogy a CPU alatti hardver-eszközök virtuálisból a CPU által lefordított kész fizikai címekkel játszadozzanak, ahogy ez most a GPU-k esetében is történik; nem véletlen - noha más, a virtualizáció az oka -, hogy az IOMMU és VT-d megoldások terjedőben vannak. De ez nem is nagy probláma, szinte minden következő generációs APU-nál szóba került már a virtuális címterek megfelelő kezelése.

    A multitasking ill. a DoS-szerű nevek pedig - a WebGL-től elszakadva, általánosan is - egyszerű dolgot takarnak: bármikor "túlterhelem" kisebb-nagyobb mértékben a GPU-mat akár most is, jól megírt, jószándékú programokkal. Egy gyors példa: egyszer elindítottam a folding@home-ot, a háttérban szépen futott; hogy megnézzem, milyen sebességgel, rákattintottam a Status-ra, ami elvileg egy kis 3D-animált ablakban mutatja, hogy hol jár éppen a számítás. Elvileg, mert innentől a VGA-m úgy döntött, hogy vannak fontosabb dolgai is az életben, mint a képernyőn levő képet kezelni és frissíteni, onnantól több, 30 perc volt a Ctrl+Alt+Del - Task Manager - Processes fül (ami folyamatosan frissül ráadásul) - End Process Tree utáni OK-ig; felületes szemmel lefagyott a gép, mivel kb. 5 perc volt az első reakció (Windows 7 alatt addigra rég elszállt volna kékhalállal). Mindezt egyetlen program okozta, ami nem volt felkészülve a relatíve gyenge GPU-ra. Ez extrém példa, de azt nem biztos, hogy jó szemmel fogják nézni a felhasználók, ha pl. egy GPU-gyorsított hosszabb videokonvertálást karba tett kézzel kell végigülniük, mint a régi szép DOS-os időkben, mert még böngészni sem nagyon lehet mellette, lévén az is GPU-gyorsított. Erre már nem olyan egyszerű a megoldás, de a megszokott felhasználói élmény ki fogja kényszeríteni.

    Mindkét probléma megoldása visszavesz az általános gyorsaságból, de ez egy-két generáció alatt utolérheti magát. Ma sem emlegeti már senki, hogy mennyivel gyorsabbak lennének a játékok, ha egy egyfeladatos, lapozás nélküli OS-sel, flat címzéssel futnának. :)
    Ha ezeket megoldják IGP-ben, következő lépésben vagy akár más ugyanabban bizonyára a saját házon belüli diszkrét kártyákkal való együttműködés is megoldottnak tekinthető.

    Consumer OS-nek pedig tekinthető a Windows is, pont arról beszélünk, hogy a Microsoft-nak mi az érdeke itt. Gyakran hangoztatod, hogy az NV nagyon készül a Windows 8-ra, nem hiszem, hogy olyan mértékben előtérbe helyezi itt a CUDA-t a C++ AMP-pal szemben, mint ahogy teszi azt az OpenCL esetében.

    Viszont a leírt teljes gondolatmeneted valóban helyes, ha úgy nézzük, hogy mire leírtak teljesen kidolgozásra kerülnek, oly mértékben elveszthetik jelentőségüket a diszkrét kártyák a jól fejlett, integrált GPU-kkal rendelkező APU-kkal illetve a platformokkal szemben, hogy nem is lesz érdemes mixelésben gondolkodni.

    [ Szerkesztve ]

    Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙

  • P.H.

    senior tag

    válasz Abu85 #31 üzenetére

    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.

    Ezt megoldották az NV helyett az IOMMU-val (és gondolom, a VT-vel). Bár gyakorlati alkalmazását a virtualizáción kívül még nem láttam, de ez csak egy az IOMMU által nyújtott szolgáltatások közül. A chipset megfelelő részeire ültetett TLB-k tartalma a futó processekének megfelelő, és lehetőséget ad arra, hogy - az eddig a GART által biztosított kernelmemória-hozzáférésen kívül - a device a megfelelő process teljes user-space memóriájához is hozzáférjen, közvetlenül, védetten, azzal a feltétellel, hogy HDD-ről való belapozást nem tud kiváltani.

    [link]

    The I/O Memory Management Unit (IOMMU) is a chipset function that translates addresses used in DMA transactions and protects memory from illegal access by I/O devices.
    The IOMMU can be used to:
    • Replace the existing GART mechanism.
    • Remap addresses above 4GB for devices that do not support 64-bit addressing.
    • Allow a guest OS running under a VMM to have direct control of a device.
    • Provide fine-grain control of device access to system memory.
    • Enable a device direct access to user space I/O.

    2.2.1 Replacing the GART
    The GART is a system facility that performs physical-to-physical translation of memory addresses within a graphics aperture. The GART was defined to allow complex graphical objects, such as texture maps, to appear to a graphics co-processor as if they were located in contiguous pages of memory, even though they are actually scattered across randomly allocated pages by most operating systems. The GART translates all accesses to the graphics aperture, including loads and stores executed by the host CPU as well as memory reads and writes performed by I/O devices. Only accesses whose system physical addresses are within the GART aperture are translated; however, the results of the translation can be any system physical address.

    Unlike the GART, the IOMMU translates only memory accesses by I/O devices. However, with appropriate programming, a host OS can use the IOMMU as a functional equivalent of the GART. First, the host OS must set up its own page tables to perform translations of host CPU accesses formerly translated by the GART. Then, to set up the same translations for I/O device-initiated accesses, the host OS must:
    • Construct I/O page tables that specify the desired translations.
    • Make an entry in the device table pointing to the newly constructed I/O page tables.
    • Notify the IOMMU of the newly updated device table entry if NPcache=1.
    At this point, all accesses by both the host CPU and the graphics device are mapped to the same pages as they would have been by the GART.

    2.2.4 User Mode Device Accesses
    The IOMMU plays a crucial role in allowing arbitrary I/O devices to be safely controlled by user-level processes, since I/O devices whose memory accesses are translated by the IOMMU can only access pages that are explicitly mapped by the associated I/O page tables. The I/O devices' access can therefore be limited to only those pages to which the user processes legitimately have access.

    Setting up the IOMMU for user-level I/O to an I/O device may be set up similarly to GART emulation with two differences: first, the mappable address range is the entire range of I/O device-generatable addresses, and secondly the operating system is not necessarily required to make exactly equivalent mappings in the CPU page tables (although most likely it will).

    Even with the help of the IOMMU, enabling user level I/O device access involves many design considerations. Protecting and remapping DMA is one part of the problem; the other part is interrupt management, for which the IOMMU provides help.

    As was the case with GART emulation, system software must assess the need to lock in memory all pages that might ever be accessed by an I/O device controlled by a user-level process.

    Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙

  • 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

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • 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.

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