- Soundbar, soundplate, hangprojektor
- Epson nyomtatók
- AMD GPU-k jövője - amit tudni vélünk
- TCL LCD és LED TV-k
- Intel Arc Battlemage B570/B580
- Apple notebookok
- Házimozi haladó szinten
- Hisense LCD és LED TV-k
- Azonnali informatikai kérdések órája
- Mikrokontrollerek Arduino környezetben (programozás, építés, tippek)
Új hozzászólás Aktív témák
-
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?
[ Szerkesztve ]
-
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
-
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.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
-
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.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ez attól függ, hogy mit tekintesz gondnak. Ha azt, hogy az OpenCL nem igazán egy mainstream programozóknak való felület, akkor azon segít a HSA, mert eliminálja a fejlesztéssel járó pöcsölést.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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...
[ Szerkesztve ]
-
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.
)[ Szerkesztve ]
-
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.
[ Szerkesztve ]
-
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.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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ű.
[ Szerkesztve ]
-
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.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
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.)
Új hozzászólás Aktív témák
Hirdetés
ph A Microsoft rendszere nem problémamentes, de a kezdő programozók számára jobb alternatíva lehet az OpenCL-nél.
- Interactive Brokers társalgó
- Samsung Galaxy Z Fold3 5G - foldi evolúció
- Futás, futópályák
- Soundbar, soundplate, hangprojektor
- Epson nyomtatók
- Autós topik
- AMD GPU-k jövője - amit tudni vélünk
- Világ Ninjái és Kódfejtői, egyesüljetek!
- TCL LCD és LED TV-k
- Drive! - Az utolsó gurulás idén a Quadrifoglio-val
- További aktív témák...
- GAINWARD GHOST RTX 4060 Ti eladó! RGB-s! Garanciával, számlával!
- AKCIÓ! ZOTAC Trinity RTX 3070 Ti OC 8GB videokártya garanciával hibátlan működéssel
- Fair Áron / NVIDIA GeForce Videókártya Felvásárlás / ORSZÁGOSAN
- BONTATLAN! ASUS ProArt GeForce RTX 4070 OC 12GB GDDR6X Videokártya! BeszámítOK
- Fair Áron / AMD Radeon Videókártya Felvásárlás / ORSZÁGOSAN
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest