Új hozzászólás Aktív témák
-
lenox
veterán
CPU-ra most nincs kedvem megirni, mert nagyon szarakodos, hogy hasznalja a simd utasitasokat, es ma mar semmi ertelme, de annak idejen megirtam es emlekszem, hogy 200 ms az mar 10 eve is lassu volt, 3-lobe lanczos filterrel volt 200 ms kb. akkor, de azokat a gepeket egy i3 is lazan veri. Nyilvan amugy a scalinget akartak mutatni, hogy mennyivel jobb az igp is, mint a cpu, ezt nyilvan sikerult, de ezek szerint a cpu es a gpu kodjaik sem tul optimalisak. Engem meg az intel igp teljesitmenye erdekelne ilyen jellegu feladatra, de az meg odebb van, amikor ki tudom probalni, de egyebkent az valahol felelmetes, hogy a c-60 hozza egy akkori workstation teljesitmenyet 9 wattbol (illetve kevesebbol, a cpu resze nincs kihajtva).
-
lenox
veterán
Na kiprobaltam, amit ok mertek (720p-rol 768-ra nagyitas bicubic filterrel) az nekem c-60 apun 19 ms lett, probaltam valami kozelebbit talalni az A10-hez, egy 9600 gt-n 4 ms. Mondjuk nincs optimalizalva, csak viszonylag naivan, szoval ennek fenyeben a 21 ms A10-en az gazosan lassu.
#59: Ahogy con_di_B is irta, sokmindent meg lehet csinalni opencl-lel vagy esetleg cudaval, de azert a fix pipeline-os gfx egyes reszeit nem lehet hasonlo sebesseggel kivaltani, szoval vagy egy hibrid megoldas kell, vagy be kell vallalni, hogy lassabb lesz, mint lehetne. Szerintem amugy jatekoknal ugyan lehet villantani valamilyen specko effekttel, de nem ezen mulok a jatekelmeny, en valoszinuleg hasznalnam a fix pipelinet.
-
con_di_B
tag
"De a raszterizálás fázisáig van amiben ne tudná kiváltani?"
Ezt így nem egészen értem mire gondolsz, de ilyen szinten nem lehet belenyúlni a grafikus pipeline-ba. Vagy előtte használsz valamire OpenCL-t/CUDA-t/AMP-et (térfelosztás, urambocsá valamiféle mesh előállítás), vagy utána deferred shading szerűen, vagy eleve nem raszterizálsz.
"Azt azért gondoltam, hogy az OpenCL nem fog megjeleníteni a képernyőn semmit."
Attól még nyugodtan kiszámolhatja a raszterizációt, szóval csinálhat mindent ő is, csak sokkal kevésbé lesz hatékony, mint mondjuk OpenGL-el. Amit én látok, az alapján a textúrázó az többé kevésbé a rendelkezésünkre áll (inkább kevésbé), de ami nagy baj, azt a depth testet, ami egy write-conflictos művelet, amit a hardveres hiearchikus z-s mókák ügyesen kezelnek, olyat CL-ből nem fogsz tudni írni, ami a hardveressel versenyképes.
De igazából minél többször kérdezed, annál kevésbé értem, hogy pontosan mire vagy kíváncsi.
-
mzso
veterán
HSA/opencl alappú 3d játékokra való alkalmasság. Opengl helyett, vagy nagyrészt helyett. Gondolok itt természetesen a grafikára
A 4:2:0 dologgal már szerintem csak a renderer foglalkozik ott meg már minden adott. Legalább is nekem ez jött a madVR topic-ban lévő beszélgetésekből.
Azt hogy belül a kodek sajátossága vagy a videó szabvány miatt van-e valamilyen lumából származtatás szerintem tényleg csak ilyen Dark Shikari szintű rálátással rendelkezők mondhatnák meg.(#48) con_di_B
Azt azért gondoltam, hogy az OpenCL nem fog megjeleníteni a képernyőn semmit. De a raszterizálás fázisáig van amiben ne tudná kiváltani? -
dezz
nagyúr
Hát, még így is csak alacsonyabb fps-ek mellett működik real-time, és akkor is csak akkor, ha minden más, amit még a GPU számolóegységeivel csinálnak, belefér néhány ms-be... És még ők "szídják" az OpenCL-t (vagy rosszul értettem?), hogy nem elég gyors? Van erre egy mondás, de most inkább nem idézem.
-
Abu85
HÁZIGAZDA
A VLC sosem volt egy scaling mester. Nem akarom bántani őket, mert ingyenes a program, de nyilván azért fejlesztenek ebbe az irányba, mert érzik, hogy itt van mit fejlődniük. A 21 ms az Trinity. A Llano ennél is lassabb (~30 ms körüli a teljesítménye). A procis sebesség 200-800 ms közötti. Szóval előreléptek, de nem eléggé.
-
dezz
nagyúr
CPU esetén 100 GFLOPS-szal számolva 50 millió számítás az fél ms. Ez így nyilván elméleti, de 4s az egymilliószor több! De ki is próbáltam egy hétköznapi képszerkesztőben, ráadásul a bicubicnél jóval lassabb Lanczos-féle algoritmussal is gyakorlatilag azonnal kész lett...
Egyébként MPC-HC-ben teljesen real-time a bicubic interpoláció, igaz, az pixel-shaderes, azaz a GPU-n fut, na de a leglassabb IGP-vel is megy rendesen, akár 60 fps-es videókkal is, azaz mindenképpen 16ms alatt kell lennie. Ehhez képest a 21ms egy Llanón, nos nagyon lassú!
Nekem úgy tűnik, hogy egy amúgy nagyon rossz kódot próbálnak átvinni OpenCL-re, amitől persze gyorsul, de úgy is sokkal lassabb annál, mint lehetne!
-
Abu85
HÁZIGAZDA
Maga a számolás nem kevés. Egy 720p-s videónál az 1080p-re való skálázás a fejlesztők szerint 49 766 400 számítást jelent. Egyébként Bicubic interpolációt használnak ehhez.
Jó kérdés. De jelszótörő azért nem a legjobb alternatíva ide. Majd, ha előjön még valaki OpenCL-lel gyorsítható tömörítővel, akkor az jó lehet összehasonlítási alapnak. A Corel fejlesztésére úgyis reagálni fognak a többiek.
-
dezz
nagyúr
4s/frame!? Miféle scaling ez, hogy ilyen borzalmasan lassú?
Bár a kitömörítés nem teljesen ugyanaz, mint a betömörítés, de nem érzel itt valami ellentmondást, hogy az ElcomSoft jelszótörőjének sokszoros gyursulásával szemben a WinZIP-ben csak ilyen 20-30% van?
Jó, kicsit jobban belegondolva, az első esetben sok kis kitömörítési próbát lehet indítani más-más jelszavakkal, párhuzamosan. De ha nem lehet betömörítéskor is párhuzamosítani a ZIP-et, akkor magát az algoritmust kell átírni párhuzamosíthatóra! (Pl. hogy kis chunkokat kvázi függetlenül tömörítsen, nem csak egy streamben.) Amúgy is van erre lehetőség a WinZIP-ben a ZIPX konténer keretein belül. Így a normál kitömörítés is gyorsítható lenne (ha épp nem a háttértár adatkezelési sebessége a szűk keresztmetszet). Lassan szinte mindenhol elérhető lesz egy OpenCL-képes GPU, így a gyorsasága által hamar elterjedhetne az új tömörítési formátum.
-
Abu85
HÁZIGAZDA
A sajátosságok az API-k velejárói. Igazából nem biztos, hogy az API a bűnös, ha az eredmény nem az, amit várt a programozó. Persze nem kizárható, de sok dologtól függ ez, hogy helyből az API legyen a felelős.
A HSA nem rendelkezik grafikus futószalaggal. Arra viszont jó, amit elküldtem korábban. A Nixxess tartotta az előadást, most nem tudom, hogy mi a pontos száma. Egyébként elméletben nyilván lehetséges, csak nem hiszem, hogy bárkit érdekelne ez a lehetőség.
(#46) dezz: Ez így van, mindig van lehetőség optimalizálásra, de nem hiszem, hogy a Corel programozói olyan hülyék lennének az OpenCL-hez, hiszen egy ideje mindent erre építenek. Biztos, hogy tudnak javítani az algoritmuson, de nem lesz jelentős a gyorsulás.
A WinZIP működik, de nem mindig hoz gyorsulást. Főleg APU-val gyorsít. Dedikált GPU-hoz jellemzően GCN kell, hogy lásd az előnyt. Az sokkal hatékonyabban dolgozik, mint a régi TeraScale architektúra.Konkrét adatokat tudok mondani a VLC-re. A scalingnál 720p-s videó 768p-re rakása A10-4600M-es processzorral átlagosan 402 ms/frame. Gyorsítva 21 ms.
A de-noise 720p-s videón 15 ms CPU-val, míg 4,2 ms gyorsítva. A de-noise esetében az a probléma, hogy az IGP kihasználtsága még 1080p-ben sem jó. Nyilván jobb is lehetne a gyorsulás.
Példának bármit fel lehet hozni. Nem akarom én a GIMP és a Photoshop implementációjának az értékét csökkenteni. Természetesen ezek is nagyon jók.A DirectCompute nem teljesen a DX runtime része. A része lehet, de külön is működik. A C++ AMP így fog működni, és így kerül oda az OpenCL runtime helyére a DirectCompute runtime. A DX runtime az legacy útvonalon megy természetesen. Ha a DirectCompute a DX-en keresztül van meghívva, ahogy az eddigi játékokban például, akkor nem működik a HSA-val.
Egy éve tervben volt. Idén ez kikerült a tervek közül. De elméletileg lehetséges a GPU-kra a HSA wrapper réteg, szóval bármikor megoldható. Az AMD nem azért vette ki ezt a tervekből, mert gond van a megvalósítással, hanem azért, mert 2014-re a GPU-piac mérete az OEM gyártók meglátása szerint fele/harmada lesz a mostani szintnek. Ilyen igények mellett nem biztos, hogy van értelme megcsinálni a támogatást.
Biztos nem fogja a BOLT az OpenCL szintet hozni, de a befektetett munka sokkal kisebb. A mainstream programozók vannak megcélozva. A többiek természetesen maguk is megoldhatják.
-
lenox
veterán
Persze, ilyet lehet csinalni, en is csinaltam korabban 'brightness-saturation curve'-ot, szepen meg lehetett adni az osszefuggest freeform curve-vel, meg animalni, stb, par szaz filmet biztos csinaltak is vele, cpu es gpu verzioja is volt, nyilvan gpu-n realtime ment (illetve meg megy is). De ez azert creative effect, ugy ertem nem automatikusan rakodik ra mindenre, hanem ahogy a colorist allitgatja.
-
dezz
nagyúr
Lehet csinálni olyan effektet, hogy pl. minél világosabb egy pixel, annál szaturáltabb, vagy épp fordítva. (Régebben csináltam is ilyeneket, szuperoptimalizált 68k ASM-ben röpke néhány s alatt le is futott, konverziókkal [RGB->YUV, YUV->RGB] együtt. Akkor ez irtó gyorsnak számított.
Ma már ugye ms-ek, különösebb optimalizálás nélkül is, azaz egy 1000x gyorsulás befigyelt. De ma már számomra ez inkább csak érdekesség.) -
lenox
veterán
Hat en csak olyat tudok elkepzelni, amilyet irtam, hogy mivel az u,v konzumer cuccoknal alulmintavetelezett, ezert az y csatornaval lehet segiteni a rekonstrukciot, olyanra gondolok pl, hogy egy el egyik oldalan ilyen szin van, masik oldalan meg olyan, de ha yuv 420, akkor 4 pixelhez tartozik egy u es v, viszont y alapjan pixelenkent is lehet jobb u,v-t szamolni. Ilyet csinaltam mar, nyilvan nem 8 biten.
#42: Pont te csináltál ray-tracelt demókat/benchmarkokat. Mi a véleményed?
Igy hirtelen nem tudom, hogy mirol mi a velemenyem?
-
con_di_B
tag
Ez a "kínlódni kell" ez általában a "nem ért hozzá egyik emberem sem" szinonímája.
Vannak olyan hardveres megoldások, amik fontosak és csak OpenGL-ből éred el, ha raszterizálni akarsz, de mivel van CL-GL interoperabilitás, ezért biztos, hogy izgalmas custom pipeline-ok fognak készülni.
(Sugárkövetést meg nyilván CL-ben fogsz írni helyette/mellé/utána, mindenféle kombinációt csináltak már.)
-
dezz
nagyúr
-
dezz
nagyúr
Attól, hogy át van rakva, még nem következik, hogy normálisan csinálták meg. Attól, hogy valaki tud programozni, még nem biztos, hogy jó programozó. (Néha ez egy egész csapatra is igaz.) Sőt, néha olyan idiótaságokat csinálnak, hogy az ember csak néz, és normálisan megcsinálva 10x gyorsabb lesz (konkrét eset!). Ezt most azért írom, mert számomra egyelőre nem derült ki, hogy a WinZIP-ben lévő gyorsítás egyátalán működik-e, vagy egyszerűen csak jobban kihasználja a többmagos procikat (többen panaszkodtak erre, nálam sem megy egyébként) és attól van az az elhanyagolható kis gyorsulás...? A VLC is olyan, hogy bár vannak benne jó dolgok, de a megvalósítás nem valami nagy szám. Nem is értem, miért nem inkább az általam korábban linkelt tesztben szereplő, igen szép gyorsulásokat produkáló cuccokat hozod fel példának.
"A scaling az nagyon előnyös OpenCL-en, mert 20-30x-os sebességet is hoz. De a de-noising már kis előny. Persze gyorsul, de csak a Trinity APU-n és nem nagyságrendi a gyorsulás."
Na hát ez nekem pl. nagyon furán hangzik! A scaling jóval egyszerűbb algoritmus, mint a de-noising, de az utóbbi sem nagy kunszt egy GPU-nak. Azaz, pont fordítottnak kellene lennie a gyorsulási aránynak... Összehasonlítási alapnak megint csak fel tudom hozni az említett képfeldolgozó filtereket.
(#27): "Lényegében egy optimalizált felület az OpenCL-hez és a C++ AMP-hez"
Az utóbbit nem értem. Ebből és amit a C++ AMP-ról tudunk, hogy DirectCompute 5.0 kódra fordul, az jön le, hogy az a képen látható DirectX runtine->Legacy Drivers útvonalat járja be, ami kikerüli a HSA szoftverkönyezetet (vagy wrappert, stb.). Bár magának a HW-nek nyilván tudnia kell a HSA számára kötelező fícsöröket, de vajon ki tudja azt használni a Legacy driverekkel?
Egyébként a mai GPU-kra is meg lesz csinálva a HSA wrapper réteg? Vagy csak a későbbiek tudják támogatni?
"Ha a befektetett munkát nézed, akkor a HSA BOLT kód kicsivel kevesebb sorból áll, mint a serial kód. A sebessége pedig majdnem OpenCL szint."
A Bolt egy OpenCL-hez vagy C++ AMP-hoz használható library (függvény-könyvtár, lényegében előre elkészített programrutinok). Azért nem annyira jellemző, hogy valami megközelítőleg ugyanolyan optimálisan felépíthető az előre elkészített építőkockákból, mintha valaki maga építené fel az egészet "atomokból"...
-
mzso
veterán
Engem még az érdekelne, hogy a HSA mennyire alkalmas 3d játék fejlesztésre. Szokszor olvastam, hogy kínlódni kell az opengl sajátságaival, hogy a megfelelő eredményt és teljesítményt hozza. Mím HSA/OpenCL alatt úgy és azt csinálhatnának az emberek ahogy akarnak (enyhén sarkítva
).@lenox
Pont te csináltál ray-tracelt demókat/benchmarkokat. Mi a véleményed? -
Abu85
HÁZIGAZDA
A múlt évben is felkerültek a netre az AFDS anyagok, idén is fel fognak. A mikort nem mi döntjük el.
Több Stage Video megoldása van az AMD-nek. Az alap fut HD 4000-en is szóval túl sok követelménye a hardver felé nem lehet. Az 1.5 a Brazosra szabott, és ennek egy módosítása van a többi DX11-es hardverre. A 2.0-s verzió a GCN architektúrára készült. Az 1.5-2.0-s verziók sajátja, hogy mindegyik igényli a Radeon hardvert, mert SAD és QSAD/MQSAD utasításra épülnek. Maga a driverbe épített kód is CTM, vagyis hardverhez szabott. Ez van integrálva a VLC-be. Ez persze lecserélhető egy OpenCL-es megoldásra, amit a VLC ír, de amíg ez nem történik meg, addig csak AMD-s fícsőrről van szó. Ez csak a fejlesztőkön múlik.
Az a gond, hogy nincs elég feladat, hogy a stream procikat kihasználják. Ezért akarnak több dolgot párhuzamosítani. Így jobb lehet a kihasználtság. Jelenleg a Y U V egymás után fut és nem párhuzamosan.
-
lenox
veterán
En ezt nem igy latom, egyreszt az amd-nek erdeke, hogy terjedjen az ige, masreszt aki ott volt nem azert fizetett, hogy a 10 oldalas papirt elolvassa, hanem hogy eloben hallja, szemelyesen talalkozzon az eloadokkal, kerdezzen ha ugy adodik, networkoljon.
Nem annyira latom, hogy mit csinalnanak a stage videoval azon kivul, hogy nem kell copyzni, azt meg biztos nem licenszelnem, mikor van vagy 10 sornyi kod...
Az etetes alatt mit ertunk? Hogy jol tudjak kihasznalni a stream procikat? Csak mert ha amugy is valamilyen bandwidth (memory vagy bus, attol fuggoen, hogy mi a platform) a szuk keresztmetszet, ami viszont boven eleg yuv hd videohoz, akkor nem olyan nagy problema, hogy nincsenek a feldolgozoegysegek kihajtva, ha nincs annyi szamolni valo, hat nincs annyi.
-
Abu85
HÁZIGAZDA
Gondolom idővel a VLC nyilvánosságra hozza. Addig várni kell. Az AFDS anyagokat az AMD felrakhatja majd a saját oldalára, de csak azokat, amiket ők adtak elő, vagy engedélyt kaptak rá az előadótól. Valaki ezt nem engedélyezi, vagy kivesz részeket az eredeti előadáshoz képest. De itt a fő gond, hogy aki kint volt az keményen fizetett azért, hogy ezeket megnézhesse. Szóval sportszerűtlen ingyen mély vízbe dobni az anyagokat, azokkal szemben, akik kint voltak. Később nyilván elérhetők lesznek.
A zero-copy-t használja szinte mindenki. A közös címtér viszont jóval kényelmesebb.
A Stage Video kiváltható ez tiszta sor. A gond az, hogy a VLC nem ír másik algoritmust, hanem az AMD-ét használja. Ez már megköti a fejlesztők kezét, mert az AMD nem fogja engedni, hogy más hardveren fusson. Nem a kivitelezhetőséggel van baj, hanem a jogi résszel.
Probléma mindig lesz. Ha nem lenne, nem fejlődne tovább semmi. Ezekre is mindig lesz valamilyen megoldás. Persze lehet, hogy az adott probléma nem jelentős. De meg kell oldani. A VLC-nél a data copy és az etetés a gond. Utóbbi szerintem nagyobb, így főleg erre kell megoldást találni. Több részt kell párhuzamosítani. -
lenox
veterán
A vlc-s prezentaciot latni lehet valahol? Csak kivancsi vagyok, nekem ilyen problemaim nincsenek, pedig ugyanezeket meg tobbet is csinalok, persze egyelore diszkret gpu-n. Amugy copyzni mar regota nem kell, pl. az amd opencl programming guide-ba is benne van, hogy fusion-nal mi a leggyorsabb modszer, ha a cpu allit elo adatot (kitomorit videot), amit opencl-lel fel akarsz dolgozni. A stage videot meg szerintem kivaltja az opencl/opengl vagy az opencl/directx interop, nekem az opencl/opengl mukodik amd-n es nvidian is, itt sem kell copyzni, egy gl buffert tud irni az opencl. Mondjuk mar tobbszor mondtam szerintem, hogy uj mmu meg kozos cimter ez jol hangzik, de amit konkretan szeretne az ember, hogy a hardver csinaljon az mar ma elerheto, csak kicsivel korulmenyesebb, egy medialejatszo az viszont elegge konkret dolgokat igenyel, hogy ne legyen vele problema.
-
Abu85
HÁZIGAZDA
Lényegében egy optimalizált felület az OpenCL-hez és a C++ AMP-hez (és később ez bővíthető, most felkerült a natív C++ támogatása egy későbbi implementációban). Sok részből áll, de röviden az a célja, hogy a programozó annyi munkát fektessen be, mint amennyit a serial kódba fektet és megközelítőleg azt a sebességet kapja, amit OpenCL-lel.
Természetesen heterogén programozásról szól az egész.Aki volt az AFDS-en az kapott ehhez belépőt, de szerintem, amint elfogadják a draft specifikációt véglegesnek, letölthetők lesznek a szükséges doksik és eszközök a HSA alapítvány weboldalán. Nyilván aki kifizetett több száz dollárt, hogy ott legyen az AFDS-en némi előnyt kap.
[link] - itt van egy kép, ugyanarról az eljárásról, csak különböző módon kódolva. Ez egy A10-5800K-n ment. Ha a befektetett munkát nézed, akkor a HSA BOLT kód kicsivel kevesebb sorból áll, mint a serial kód. A sebessége pedig majdnem OpenCL szint. Ezek a példák szintén elérhetők lesznek később.Azt még nem tudni, hogy az 1.0-s draft speckókat mikor fogadják el. Az AMD nyilván kész van, így ők már ma szavaznának, de a többi partnernek el kell készülni a finalizerrel, amit mindenki saját maga ír. Módosítani valszeg nem fognak a draft speckókon, mert ezt mindenki jelezte, hogy eleve együtt dolgozták ki, szóval nagyjából megfelel mindenkinek.
(#26) mzso: Az OpenCL az az, szerintem a C++ AMP sem az az igazán mainstream rétegnek szánt megoldás.
Az Adobe előadásán volt róla szó, hogy ma nagyjából 100 000 jó GPU programozó van. Míg a mainstream programozók száma nagyjából 10 millió. Az Adobe szerint a HSA-val úgy 1-3 millió programozó lesz, vagyis jóval több program születhet, mint most. Most az Adobe 200 programról tud, plusz-mínusz valamennyi. A HSA-tól százezret várnak. -
con_di_B
tag
Miért, mit tud a HSA? Persze, híreket olvastam róla, de egyikből sem derült ki, hogy PONTOSAN micsoda lesz. Még a legkonkrétabb dolog az volt, hogy egy közös low-level hardver API, amire közös (open-source) OpenCL implementációt fognak készíteni a HSA tagok. Ez max. a heterogén környezetnél érdekes, de a programozónak alapból ettől nem lesz könnyebb.
Amennyire én tudom, ami a fejlesztőknek közvetlenül szól, az az OpenCL HLM.
-
Abu85
HÁZIGAZDA
A WinZip esetében szinte minden lényeges rész át van rakva OpenCL-re. Ennél nem lehet többet tenni, maximum optimalizálni a kódot, ez persze nem árt, meg jöhet a támogatás nem AMD-s hardverekre is. Szóval a 17-es verzió főleg az optimalizálásból és a támogatás kiterjesztéséből áll majd.
A VLC problémásabb, mert ott nem mindent érdemes átrakni GPU/IGP-re még. Erről volt a fejlesztőknek egy előadásuk az AFDS-en. A scaling az nagyon előnyös OpenCL-en, mert 20-30x-os sebességet is hoz. De a de-noising már kis előny. Persze gyorsul, de csak a Trinity APU-n és nem nagyságrendi a gyorsulás. A legnagyobb problémájuk, hogy lassú a data copy, valamint nem tudják etetni az IGP-t még 1080p-s anyagnál sem. A data copy problémáját megoldja majd a Kaveri, illetve a Trinity-nél a HSA-MMU használata, míg az etetést úgy képzelik el, hogy a három fázisból álló munkát megpróbálják párhuzamosítani. Ez elmondásuk szerint nem könnyű, de nem lehetetlen.
A Stage Video szolgáltatás pedig konkrétan az AMD driverekbe integrált fejlesztése. Ez sosem fog működni a konkurens hardvereken, mert ez nem a programon belül valósul meg. Persze a VLC írhat egy saját megoldást, ami már működhet, csak erre egyelőre nincs terv. A Stage Video szorosabb integrálására van terv, de az AMD ezt csak úgy engedi, ha vendor lockos lesz. Mivel az algoritmushoz szabadalom kötődik, így ha ezt használják fel, akkor muszáj nekik kizárni a nem AMD-s hardvereket, vagy azokat, amiken az AMD nem szeretné, hogy fusson. De nyilván megoldható úgy, hogy ne legyen probléma a szabadalomból. Van már több ilyen algoritmus, ami működik. -
lenox
veterán
GIMP-et, AfterShot Pro-t és Musemage-t meg nem hasznaltam, de vlc-t meg winzip-et igen, az adobe-nal meg volt kollegam a videos termekek termekfelelos igazgatoja.
Amugy az a vicces, hogy megint olyan bugot talaltam az amd es nvidia opencl implementacioban, ami mindkettonel szar, de az amd-nel jobban...
-
dezz
nagyúr
Szerintem sorra fogják átírni a filtereket. A linkelt teszben egyébként a GIMP, az AfterShot Pro és a Musemage is szerepel.
Ha viszonylag kis idő (és tudás) belefektetése mellett használható teljesítményt hoz ez a C++ AMP, akkor szerintem sajnos eléggé elterjedhet. Ugyebár azért sajnos, mert nem hiszem, hogy utólérhetné teljesítményben az OpenCL-t, és amúgy is korlátozottabb (ha jól vettem ki, pl. független a HSA-tól). Remélem, aki kicsit ad magára, az az OpenCL-t fogja használni. (Kommersz programokat illetően. Egyedi fejlesztésre tőlem használhatja a CUDA-t is.
) -
lenox
veterán
Winzip meg VLC amennyire en ertem meg eppenhogy elkezdte tamogatni az opencl-t, mint ahogy az Adobe is.
En is kivancsi vagyok a c++ amp elterjedesere, az, hogy egyelore csak windows tamogatas van, szerintem jelentos hatrany, cuda meg opencl mar eleg jol fut mac-en, linuxon is, valamit nagyon kell tudjon, hogy ennek ellenere azt valassza az ember. Jelenleg inkabb ellene fogadnek.
-
dezz
nagyúr
"ha konzumer appot fejleszt valaki, de olyan meg nem sok van, ami mar eddig is tamogatott opencl-t"
Azért van egy pár (az Abu által emlegetett WinZIP-en és VLC-n kívül is), nem is akármilyen szinten használják ki a GPU-kat! [link]
És nyilvánvalóan egyre több lesz. Van egy pár terület desktopon is (és persze WS szinten sem csak egyedi fejlesztések vannak), ahol a teljesítményből még messze nem "elég", márpedig a sima többszálúsítás egyre kevésbé pálya: az egyre többmagos procik egyre alacsonyabb órajelen férnek bele a fogyasztási keretbe, ezért nem is hozzák le desktopra, de ha le is hoznák, nem igazán érné meg a jóval magasabb árat az a nem túl jelentős teljesítménynövekedés. Az a szoftverkészítő viszont, aki rááll a GPGPU-ra, adott esetben igen jelentős teljesítménynövekedést tudhat produkálni, akár egy hétköznapi videókártyával is, ami hozzá csalogatja a vevőket. Persze ezt neked felesleges volt ilyen szájbarágosan elmagyarázni.
Kíváncsi vagyok, hogy az ilyen komolyabb programok "GPGPU-sításán" mennyit fog lendíteni ez a C++ AMP. Az ember azt várná, hogy ezeket felkészültebb programozók készítik, de ez ugye nincs mindig így. Illetve néha egyszerűen sajnálják rá az erőforrást, időt. Legalább is, amíg a konkurencia be nem előzi őket.
-
lenox
veterán
Ezek szerint valamikor ra kell nezzek a C++ AMP-re, hogy en is megtanuljam 2s alatt
. De amugy en magamtol arra tippeltem volna, hogy ha egy random programot gpu targettel forditasz, akkor nagy valoszinuseggel lassabb lesz gpu-n, mint volt cpu-n, de nyilvan meg nem probaltam... -
Abu85
HÁZIGAZDA
Ez talán érthető különbség, attól, hogy mindenkit egy cél visz előre az integrálásnál, még képzelhetik ezt az egészet másképp. Nincs olyan szabály, hogy melyik hardveres felépítés hatékonyabb a másiknál. Sőt, szerintem ebben a kérdésben senki sem biztos, csak az elmélet és a meglévő technológiák alapján döntöttek egy irány mellett és véghezviszik. Ha a logikai szinteket nézzük, akkor előbb vagy utóbbi mindenki ugyanott fog kikötni. A mostani integráció csak a CPU és a GPU egyesítése jobb/rosszabb összekötés mellett, de a rendszer működése nem sokban különbözik attól, mintha külön lenne egy CPU-d és egy GPU-d. Annyi az előny, hogy a lapkán belüli kommunikáció sokkal gyorsabb, mint a külső linken keresztüli. A következő szint sokkal izgalmasabb. Jön az egységes címtér, így az IGP ugyanazokat a pointereket kezeli, amiket a CPU, és a grafikus vezérlő képes lesz elérni a processzor virtuális címterét, továbbá a CPU és az IGP teljesen koherens memóriát oszt meg. Az AMD ezt a GCN-nel képzeli el jövőre, így nem véletlen az sem, hogy miért ilyen az OpenCL driver. Az Intel ezt a szintet 2015-ben éri el a Skylake APU-val, amibe bekerülnek a MIC magok. Nekik más fejlesztési felfogás kell ehhez. Az NV sötét ló, mert az OpenCL annyira nem érdekli őket, de ettől jön a Maxwell APU 2014-ben, ami szintén megvalósítja fenti dolgokat. Ez az időszak lesz az izgalmas. Ekkor az is kiderül, hogy ki döntött jól, és ki kevésbé jól.
Abban igazat adok, hogy AMD GPU-m van, így erről van tapasztalatom. Meg kellene nézni ezt APU-kkal. Ivy vs Trinity. Idén szerintem lesz rá lehetőség.
-
con_di_B
tag
Az Intel és az AMD CPU drivere között filozófiai különbség (is) van. Az AMD kiegészítő/vezérlő skalár processzorként tekint a CPU-jára, ennek jegyében egyáltalán nem tud vektorizálni a fordítója, az Intel pedig a legnagyobb csúcssebességre törekszik, ezért vektorizál és lock-stepezget mint az állat. Ami vagy bejön, vagy nem, de általában igen.
Az AMD CPU drivere éppen emiatt szar, mert csak nagyon speciális esetekre tud kellően nagy sávszélességet biztosítani a memóriaműveleteknél, alapvetően nem foglalkoztak a kérdéssel - még.
Az Intel fordítója viszont "fiatalabb", szóval a hibaüzenetei szinte használhatatlanok az AMD-éhez képest, ezen kívül előjönnek időnként hülyeségei, de ez egyre ritkább. Mindenesetre kókány kódot nem tud jól kezelni/vektorizálni. (Ilyesmiben legendásan az NV a bajnok.)
Ez a benchmarkra optimalizálás lehet, hogy játszik náluk, sőt, biztos, de mindenki másnál is. De azért hogy az AMD driverrel jobb legyen az messze nem egy általános érvényű igazság. Maximum akkor lehet értelme azt használni (általánosságban), ha AMD GPU-d van, és interopos alkalmazást akarsz futtatni.
A LuxMark-nál meg lehet látni azt is, hogy a CPU-GPU gap nem olyan nagy, szóval esélyes, hogy nem annyira a peak sebességre érzékeny. Ha GPU barátabb lenne a cucc, máris nem így festene az Intel/AMD driver viszony.
-
Abu85
HÁZIGAZDA
A bináris formátummal kisebb a kód is. Nem kell megírni a compile részt.
Jelenleg elég sok a hackelés ... legalábbis a multimédiás szoftverek piacán. Ez egy elég gyilkos szegmens, és a teljesítmény vásárlót hoz, így mindent be kell vetni. Ebből a szempontból persze biztos, hogy nem volt ideális szórás a megkérdezett fejlesztők között, de ők voltak elérhetők. -
LordX
veterán
Aki ért C++-hoz, annak a C++ AMP kb. 2s alatt megtanulható, mivel a C++ AMP = C++ egy darab új kulcsszóval (restrict). Konkrétan egy random C++ programot pár perc alatt le lehet fordítani GPU targettel - persze ez messze nem jelenti azt, hogy az a kód jó is lesz, de mindenesetre jó eséllyel gyorsabb lesz, mint a CPU-s bináris - csak nem 50x (mármint ha olyan a probléma), hanem 1,5x.
Na, ezért tetszik az embereknek - alacsony a bekerülési költség. Ez nem mondható el OpenCL-ről, ott egy új nyelvet kell megtanulni, akármennyire is C-szerű.
-
Abu85
HÁZIGAZDA
[link] - Itt van egy OpenCL CPU driver összevetés. A Core i7-3770K proci az AMD driverével gyorsabb, mint a sajáttal. Én is az AMD OpenCL driverét használom az Intel procimhoz, mert gyorsabb tőle egy OpenCL-es valós program. Az Intel OpenCL drivere egyedül szintetikus benchmarkokban jobb a méréseim szerint. Azokra gondolom optimalizálva van. Ez nem mellékes ugyan, mert mutatja, hogy mit lehetne belőle kihozni, de én valós programokat futtatok. Ezért mondom, hogy erre az Intelnek figyelnie kell, sőt, pénzt kell rakni ide, mert cool, hogy a CLBenchmarkra, meg még nem tudom, hogy milyen benchmarkra ráoptimalizálnak, csak ez addig nem ér semmit, amíg a VLC és a WinZip, amit ~10 millió felhasználó futtat nem megy az Intel OpenCL driverével. A usert a valós alkalmazás érdekli, és nem a benchmark. Megvan utóbbinak is a szerepe, csak a felhasználó szemszögéből nem sok.
Ha az OpenCL erősítése opciót választják, akkor azt kell tenniük, hogy küldenek programozókat és anyagi támogatást a valós alkalmazások fejlesztőinek. Emellett el kellene érni, hogy az OpenCL-es programokat ne APP SDK-val csinálják. Ez ugyan nem zárja ki, az Intel és az NV hardvereire való fejlesztést, de az AMD semennyire sem figyel a konkurencia hardvereire. Ezt a driveren is lehet érezni. Nem zárják ki azt, hogy telepítsd Intel procihoz, de régebben jeleztem egy minőségre vonatkozó hibát, ami a vRevealban a driverükkel előjött. Az volt a válasz, hogy AMD procival nem jön elő, és ők az Intel hardvert nem hivatalosan támogatják. Kipróbáltam az AMD-s gépen, és tényleg nem jött elő. Nem azt mondom, hogy tolják úgy a programfejlesztéseket ahogy az AMD, vagy az NV, de azért jobban kellene figyelni. Az OpenCL nem csak benchmark optimalizálásból áll.
A bármit állít az Intel a MIC az GPU, mínusz a fix-funkciós egységet, de ezek a konzumer IGP-ben ott lesznek. A MIC egyedüli előnye, hogy a mai GPU-knál jobban támogatja a C++-t. Mást nem lehet felhozni. Az mézesmadzag, hogy a meglévő kódok újrafordítása kis módosítással jó lesz. Kétségtelen, hogy működni fog, csak nem fog jól skálázódni.
-
flugi
tag
Nagyon furcsák a fejlesztők, akik nyilatkoztak, vagy valami félreértés van.
Az, hogy létezik bináris interfész, az legfeljebb gyorsít, de nem segít a kompatibilitáson, legfeljebb akkor, ha a fejlesztők valamilyen driver-függő hackelést alkalmaznak, és az új driver "csak" a specifikációt hozza, a hackelést meg eltöri. Aki így programozik, annak nem való egyáltalán a template-alapú GPU programozás.
Aki ugyanis ilyen hákolásokat használ, az azért teszi, mert nagyon szorítja a teljesítmény igény, és legszívesebben alacsonyabb szinten programozna. Erre egyébként van mód mind AMD-n, mind NVidián, ami pont annyira támogatott, mint a fenti hákolás, tehát semennyire, vagy minimálisan
Hasonló a helyzet a profilozással is. 15-20%-os teljesítménykülönbségek a template-alapú GPU programozás esetében épp semmilyen intézkedést nem indokolnak, mivel ha a GPU-n még lehetne húzni 20%-ot, és elérnénk a technológiai határt, akkor éppen többtízszeresen gyorsabbak vagyunk, mint a CPU, tehát mission accomplished, nem kell többet dolgozni.
Könyörgöm, a template-alapú GPU programozás lényege az, hogy CPU jellegű eszközökkel gyorsabb programot kapunk. Nem az, hogy majd CUDA meg OpenCL helyett használjuk.
-
con_di_B
tag
Az Intelnek nem kell félnie az OpenCL-től. A mostani GPU szériájuk is meglepően jó OpenCL-ben (lásd: http://clbenchmark.com/compare.jsp?config_0=12783508&config_1=11976878 ), az AMD CPU-i pedig alapjáraton is elég satnyák, de ráadásul az AMD drivert is elfelejtett írni alájuk, ami azért ügyes tökönlövés volt maguknak. (GCN más kérdés, az nevel.)
Ez most csúnya lesz, de ha belegondolsz, akkor az Intelnek mit kéne tennie? Tartson szemináriumokat az optimalizálásról, amire már költött helyette a másik két gyártó?
Viccet félretéve, nyilván nem okozna gondot nekik saját support, de NV/AMD szinten tudtommal nem tolnak ők semmi mást sem. Ez nem jelenti, hogy ne érdekelné őket a dolog.A MIC pl. elég erősen tud profitálni az OpenCL programozási modelljéből, de azt is érdekes figyelni, hogy ők nem erre verik magukat, hanem, hogy mire jó az x86 rajta. Szóval inkább azt hangsúlyozzák, amiben más, mint egy GPU.
-
Abu85
HÁZIGAZDA
Az NV-t értem, nekik a CUDA a lényeg. Egyébként lehet, hogy a lassú dologban van valami, mert az OpenCL 1.1-es driverük sebessége igen nagy visszalépés volt az OpenCL 1.0-shoz képest, azóta sincs változás. A WinZip erre érzékeny is lehet a data-copy miatt.
Az Intelnél azt érzem, hogy a kezdeti lelkesedés kezd megszűnni. Inkább a fejlesztőkre bízzák az egészet, írnak blogokat, tartanak webes gyorstalpalókat, és kész, egyelőre ennyi. Nekik szerintem nem tetszik a HSA. Az az OpenCL és C++ AMP programokból profitál, és az nem jó az Intelnek, függetlenül attól, hogy az OpenCL-ből profitálhatnak. A nagy kérdés szerintem náluk, hogy melyik a rosszabb. Anyagilag segíteni az OpenCL-t, és ezzel arra vinni a programfejlesztést, amerre az AMD szeretné, vagy egyelőre állni egy helyben, és nézni, hogy mi történik. Egyik sem kockázatmentes. Előbbinél ott a GCN architektúra hatékonysága és tudása, amilyen szintet leghamarabb 2015-ben tudnak integrálni a Larrabee/MIC IGP-vel rendelkező Skylake-nél, míg utóbbinál az AMD pénzeli a projekteket, és ha azt nem is várják el, hogy ne fusson máson, azt elvárják, hogy AMD hardverekre legyen optimalizálva. Ez önmagában nem jelent gondot, de láttuk már a Battlefield 3 esetét. Bulldozer CMT-szerű többszálúságára optimalizálták, és rosszul fut HyperThreading mellett. [link] - ezt patchelik, de teljesen nem tűnt el a gond. A HyperThreading Off a legátfogóbb megoldás még ma is. Nem egyszerű ez a helyzet. Mindkét opció oroszlánbarlangba vezet. Az Intelnek egy CUDA-szerű saját platform kellene, csak az nincs.
Hát, igen. Az open source közösség nem életbiztosítás. Sokszor nagyobb a füst, mint a láng, de alkottak ők már nagyot.
-
con_di_B
tag
Az NV hivatalból le*ja az OpenCL-t, ennek ellenére teljesen tisztességes OpenCL supportjuk van, mivel a CUDA-ra rá tudták építeni. Elég valószínűtlen, hogy ne sikerült volna valamivel marhára mellényúlni a kódban, hogy azon ne fusson. Egyrészt mindegyik gyártónak van pár baromi jó ötlete, ami a szabványban egyébként nincs benne, de ami valószínűbbnek tűnik, hogy szimplán csak baromi lassú lett NV-n, és egyelőre nem merik ezt így kiadni, vagy nem erre számítottak. Az Intel meg eléggé tolja a témát, meg hagyománya van az Intel optimalizált szoftverfejlesztésnek, szóval nagyon meglepne, ha nem kapnának supportot hamarosan.
Szóval ezt az AMD limitációt ne vedd annyira komolyan. Lehet, hogy ebbe speciel ők talicskázzák a legtöbb pénzt, de összesen nincs akkora súlyuk, hogy ez tartósan így maradjon, meg aztán, a többieknél sem hülyék ülnek.
A C++ AMP meg azért távolról sem ennyire kigyúrt concept, eléggé látszik a dolgon, hogy ez a szokásos Microsoftos publikus pilot project. Hozzáteszem, ez a része nem személyes tapasztalat az AMP-ról, inkább csak benyomás, de azért nem lenne tőlük példanélküli ez a fajta hozzáállás. Éppen ezért is tartom valószínűtlennek, hogy nagyon nekifeküdne ennek bárki.
Open source meg tudtommal még a CLR-ből sem született normális a Mono-ban, attól nem félek, hogy ezúttal másképp lenne.
-
Abu85
HÁZIGAZDA
Azt nem merném állítani, hogy nem fogják implementálni Windows-on kívül. Manapság elég sok project indul Linuxra. Szerintem ebbe is belekezd az open source közösség.
Az AMD rakja a legtöbb pénzt az OpenCL fejlesztésekbe. Utánuk az Intel és végül az NV (nekik a CUDA a fontos, szóval érthető). A pénznek a fő eredménye, hogy van a WinZip-ben és a VLC-ben OpenCL támogatás, de csak akkor, ha a driver az AMD-é. NV driverrel a Scaling opció megy a VLC-ben, de a többi csak AMD driverrel. Intel driverrel semmi nem megy, ami OpenCL. Az x264 OpenCL támogatását is teljes egészében AMD finanszírozta, noha elvileg meg lesz oldva a többi hardveren is a támogatás, de ez nem biztos. A finanszírozás fejlesztésre megy, vagyis nem arra, hogy másnál ne fusson, nincs tehát feltételes elágazás a programban, hogy ezen, meg ezen ne menjen. Szimplán az a baj, hogy nem elég fejlett az OpenCL támogatás. A WinZipes fejlesztést megértem, mert adatok tömörítéséről van szó, nagyon nem mindegy, hogy az eredmény jó lesz-e, de egyértelmű, hogy jelenleg sokkal több pénzt kellene a gyártóknak tolni az OpenCL-be. A programtámogatásból látva egyedül az AMD veszi komolyan, és ma már eljutottunk oda, hogy open szabvány ide vagy oda, de limitálva van pár program az AMD hardverekre és driverekre. Pont egy open szabványnál nem kellene ennek így lennie. Ez rossz. Persze rosszabb, ha hibásan fut, de egyelőre nem valami korrekt a helyzet. A C++ AMP jobb lehet. A DirectCompute támogatásra az Intel és az NV sokkal jobban figyel. Ez is fontos lehet a cégeknél, amikor készítik a támogatást.
-
con_di_B
tag
Esélyes, hogy ellesznek egymás mellett, mivel teljesen másra valóak. C++ AMP-pel fine tune-os tökig optimalizált megoldásokat biztos, hogy nem fognak szállítani, de a gyakorlatban erre elég kevés az igény.
Amikor mégis van, akkor tudvalevő, hogy drága programozók fogják sokáig fejleszteni, sok-sok zsákutcával és a végeredmény teljesítménye sem valami jól tervezhető, szóval kockázatos mint project, a deployment meg rémálom lesz. De ha mégis megéri kockáztatni, vagy szükséges, akkor úgyis OpenCL-ezni fognak.
A C++ AMP-ot a kutya se fogja implementálni Windows-on kívül, ami azért lehet gond, viszont a leggyakoribb scenario-ra, vagyis meglévő kódbázis "felgyorsítására" jobban tervezhető eszköz. Ezek a felgyorsítós projektek meg eléggé a "fogalmunk sincs mennyit fog gyorsulni"/"jujjdejó, két-háromszor gyorsabb lett (egy két-háromszor többet fogyasztó videokártyán)" szinten is simán jók.
(Az eleve GPGPU-ban érdekelt ősprojectek meg már akkor GPU-n mentek, amikor még OpenCL se volt, csak shaderek.)
Ezeket az AMD-s megjegyzéseket annyira nem értem, AMD-re sem jó a deployment, nem mindig van ugyanazon a branchen az összes család drivere, lehet szívni. Mire gondoltál?
-
Abu85
HÁZIGAZDA
Korábban CUDA-val újabban OpenCL-lel foglalkoznak/tak. Egyébként a fizetős multimédiás lejátszók és videoszerkesztők általam ismert programozóit kérdeztem meg. Mivel ezek a programok korábban tartalmaztak/nak CUDA és/vagy OpenCL kódot, így gyanítom tudják hol lesznek a különbségek. Ez a piac annyira kiélezett, hogy minden lehetőséget megnéznek mint opció, így a C++ AMP-t is. Aztán maximum maradnak az aktuális kódnál, de ha jobb a C++ AMP, akkor azt ki kell használni. Előre senki sem tudja. A specifikációkat látják, de a gyakorlat a lényeg.
Azt mindenki leírta, hogy könnyebb, mint az OpenCL és a CUDA, de a komolyabb profilozó hiánya elég nagy nehézség.Én úgy gondolom, hogy az OpenCL és a C++ AMP el lesz egymás mellett. Nem feltétlenül kell ellenfeleknek lenniük. A programozó pedig szabadon választhat.
-
lenox
veterán
Mit fejlesztenek azok a fejlesztok akiket felkerestetek? Mit hasznalnak gpu programozasra? Csak C++ AMP-et? OpenCL-t, Cudat hasznaltak elotte evekig? Csak hogy el lehessen helyezni a vilagban, mert a cikk egyik resze arrol szol, hogy milyen problemak merulnek fel kulonbozo platformok eseten, ez meg akkor erdekes, ha konzumer appot fejleszt valaki, de olyan meg nem sok van, ami mar eddig is tamogatott opencl-t meg cudat, es nyilvan annak a velemenye az erdekes, akinek van osszehasonlitasi alapja.
.
Új hozzászólás Aktív témák
- BESZÁMÍTÁS! Asus TUF A620M R7 7700 32GB DDR5 1TB SSD RX 6800 XT 16GB ZALMAN I3 NEO Gigabyte 750W
- Xiaomi Redmi Note 10 Pro 128GB, Kártyafüggetlen, 1 Év Garanciával
- LG 27GR83Q-B - 27" IPS / QHD 2K / 240Hz & 1ms / NVIDIA G-Sync / FreeSync / DisplayHDR 400
- Thinkpad X230 legenda: i7 CPU, IPS kijelző, 12 GB, dupla SSD, magyar villbill, webcam, fingerprint
- Apple iPhone 16 Pro Max - Desert Titanium - Újszerű, Karcmentes,256GB
Állásajánlatok
Cég: FOTC
Város: Budapest