Köszi, így már világos minden. Tehaát az opencl lenne a legoptimálisabb megoldás számomra, de ettől függetlenü ha most cppampozok, azzal is ki tudom használni valamelyest a Kaveri előnyeit, vagy mindenképpen kell az opencl-es kiterjesztés, hogy többet érjen egy HD4600-as i7-nél? egyelőre húz a szívem az amp felé, ismerőseb terepnek néz ki, mint a többi, és egyelőre csak egy oldalhajtása a projektünknek a hardveres optimalizáció.

A vér nem válik VAZZE!™

A Kaveri előnyeit a mai napon csak az OpenCL-en belül a cl_amd_svm és cl_amd_hsa kiterjesztésekkel lehet használni.
Gondolom az AMP-ben leginkább a C++ hasonlóság húz. Ez igazából OpenCL-ben is megoldható. A legújabb APP SDK-ban van C++ Wrapper API a Khronos C++ bindings-hez.
Esetleg próbáld ki a BOLT-ot. Ez nagyon hasonlít a C++-hoz.
Ezeket a mostani hardverekkel is kipróbálhatod. A komolyabb munkához majd a tavasszal érkező Catalyst szükséges. Az már nem csak a fenti két kiterjesztést tartalmazza, hanem le lesz cserélve benne szinte minden a compute részlegen.

[ Szerkesztve ]

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

aha, tehát az új catalysttal már mondjuk a cppamp alatti driver is okosodik? nem sürgős nekem most ez a dolog, egyelőre csak tanulmányozom az ampon keresztül az egész kncepciót, és hogy hogyan lehetne ráhúzni az algoritmusainkra (elég bonyik, nem túl triviális a párhuzamosítása, még procira is problémás néhol), szóval van időm várni.
ez a Bolt library viszont szimpatikus.

A vér nem válik VAZZE!™

A Boltra lesz kigyúrva az új Catalyst. A C++AMP-hez más fejlesztés is kell. Erre az AMD nem koncentrál, mert mire változtatna a működésén addigra az MS kész lesz az új AMP-vel.

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

Hátőő, ez azért nem pontos.

Egyrészt a wrapper az kb. senkit nem érdekel, hogy C++, mert az egész OpenCL kód kb. 1%-a lesz az, magát a számítást meg írhatod C-ben (AMD-nek van egy nem portolható OpenCL C++ változata). Másrészt semmit nem wrappelnek pluszban AMD-ék, az a wrapper API egy-az-egyben a szabványban leírt C++ bindings. Nem "a legújabban van már", hanem már a legelső verziótól kezdve, mindegyik vendortól van.

A BOLT megint csak egy library - C++ interfész, OpenCL vagy C++AMP implementációval. Annak jó (de nagyon), aki nem akar belemászni mélyre, viszont ha bonyolultabb dolgokat akarsz leprogramozni, nem lehet kikerülni a 3 nyelv (CUDA, OpenCL, C++AMP) egyikét.

ezt nem teljesen értem. a bolt egy wrapper api, ami vagy opencl-el, vagy c++amp-vel valósítja meg. ha a catalyst a boltra gyúr, akkor önmagában az amp mögötti driverének is jónak kell lennie. vagy csak a bolt másik fele lesz jobb az új catalysttel? lesz új AMP?

A vér nem válik VAZZE!™

Nekik OpenCL static C++-uk van. Ez van az APP SDK-ben. Például a legújabban. Mivel úgyis a Kaveri funkcióit akarja kihasználni, így édes mindegy, hogy a kód portolható-e más hardverre.

(#656) orbano: A Bolt ma leginkább OpenCL-lel működik. A C++AMP-hez van támogatás, de ha van OpenCL driver, akkor inkább azt használja és a C++AMP-t helyezi háttérbe.
Az új Catalyst nagyfrissítés lecseréli az OpenCL részt. Az AMDIL helyett lesz a HSAIL, és az ehhez kapcsolódó funkciók. Ez lesz első körben.
A C++AMP-hez olyan rendszer lesz az AMD-nél, hogy a CLANG LLVM-IR kódot készít és abból lesz HSAIL kód. De ez nem tavasszal lesz. Tehát egy ideig marad a DirectCompute elérés.

Persze lesz új AMP, az MS is arra megy, amerre az OpenCL. Jönnek az integrációhoz kapcsolódó fícsőrök.

[ Szerkesztve ]

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

Nagyon tetszett a gyakorlatias hozzaallasod a Kaverihez. Gep epites elott allok es olvasgattam a hozzaszolasokat,de ez volt az elso igazan gyakorlatias megkozelites. En laikus vagyok hardver teren,minden igyekezetem ellenere.Hadd kerdezzem meg toled hogy az altalad emlitett ddr4 memoriak erkezese mikorra varhato. Egyik angol oldalon azt irtak hogy a 2500 ast is tamogatja... Persze teljesen igazad van benne hogy az nagyon megdragitana a rendszert,ami egyenlore onmagaban sem olcso.

ok, a tavasz nekem még nem akkora para, eleve csak áprilisban indul a projekt, addig csak felmérek. kb mikorra várható az AMP-os vonal fejlődése?
egyébként nem teljesen világos nekem, hogy ebben mit cserél és hogyan az AMD. A M$ SDK-ja mellett lesz majd egy AMD-s verzió is? VS12/13 azt ugyanúgy fogja támogatni (profiler, debug, amik miatt a legszimpibb ez a vonal), mint a M$ félét? Lehet hülyeséget kérdezek, de ez a rész nem teljesen tiszta nekem.
Köszi

A vér nem válik VAZZE!™

... és mit meg nem tennék azért, hogy ezt az OpenCL static C++-t a Khronos felemelje a standardba, hogy ne kelljen egy hülye minimalista nyelvben dolgozni..

A Bolt azt fogja használni, amit mondasz neki. Külön namespace a ::bolt::cl és a ::bolt::amp, nincs mechanika, ami automata kiválasztaná, hogy min menjen - amúgy is fordításidejű kérdés, nem futásidejű, úgyhogy sok értelme nem is lenne, és még egy lapáttal rá, hogy más is a két rész API-ja (kernel kódrészlet írásához AMP oldalon C++11, míg CL oldalon csak C99 támogatott, érthető okokból).

A Clang alapú C++AMP rendszer fejlesztését itt lehet követni (mai a milestone 2 ). De ennek inkább a Linux támogatás a célja, nem az AMD hardverek "direkt" C++AMP támogatása (konkréten egy HD4000-en működget nálam).

Szerintem Abu itt valamit félreért: Windowson a VS2012/13 fordítóját használja mindenki C++AMP-ra, ami jelenleg HLSL bytekódot csinál, amit majd a különféle vendorok drivere kap meg futásidőben. A Clang fork az csak Linuxon érdekes (amúgy sincs még olyan Clang Windowson, ami nem halna meg arra az egy sorra, hogy #include <windows.h>).

Az új AMP valszeg az év vége felé jön.
Ugye a C++AMP egy koncepcionális rendszer a single source modellre, ahol a programot mindenhol futtathatod. Ami változó lehet, hogy a forráskódodból hogyan lesz olyan gépi kód, ami majd fut. Erre ma ott a DirectCompute, de maga a C++AMP számára ez nem feltétel. Ha van valami más projekt, ami ugyanazt a kódot valamilyen más úton eljuttatja a hardverre, akkor lehet fejleszteni. Jelenleg a DirectCompute mellett fut a CLANG projekt, amivel LLVM-IR->HSAIL, vagy SPIR1.2->OpenCL driver fordítással is futtatható ugyanaz a C++AMP forrás az adott hardveren.
Ezt elsősorban Linuxhoz fejlesztették, de semmi akadálya a Windowsos implementációnak. Erre építi fel a rendszerét az AMD. Nekik bármilyen fordítás jó a Kaverihez, ha végül egy HSAIL kódot kapnak.

[ Szerkesztve ]

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

Kaveri PH-s teszt mikor lesz?

Én kérek elnézést!

hat nem egyszeru es gyors folyamatrol van szo, ez teny. de a hardverrel kell kezdeni. ha megnezed a teszteket, a HSA-s dolgoktol fuggetlenul is eros lett a Kaveri, teljesitmeny/watt aranyban eleg eros, ha jatekokrol van szo. Nekem szimpatikus, otthonra valoszinuleg veszek a 45 wattos verziobol, alkalmi jatekra, meg netezgetni, illetve tesztelni jo lesz.

A vér nem válik VAZZE!™

Lefele szépen skálázódik, ezt senki nem tagadja. De a 7850k árához képest gyenge, vagy teljesítményéhez képest drága. Plusz fogyasztása sem olyan jó a teljesítményhez viszonyítva. Felfele nem skálázódik jól, sajnos.
Abban is egyet értünk, hogy a hardverrel kell kezdeni, amivel nincs is probléma, egészen addig amíg nem akarnak prémiumot kérni olyan technológiákért, amit még nem használnak szoftverek.

"Lefele szépen skálázódik, ezt senki nem tagadja. De a 7850k árához képest gyenge, vagy teljesítményéhez képest drága. Plusz fogyasztása sem olyan jó a teljesítményhez viszonyítva. Felfele nem skálázódik jól, sajnos."

A mobil verziók (15-35W) remélhetőleg kifejezetten jók lesznek. Csak jó áron kéne adni őket; és persze a gyártóknak is szakítani a hagyományokkal és értelmes eszközöket építeni rájuk.

Egy ilyesmi cucc [link] Kaverivel hybrid CF-el nem lenne rossz.
Normalis AMD APU-s notinak igy a 4. generacional, hat nem tudom lehet a piros honak tobb eselye van

én valamivel nagyobb gépet akarok, NAS-nak is lesz tartva Feketében, teli oldallappal

A vér nem válik VAZZE!™

Igaziból nem tudom. Hátha kiderül, hogy időközben jött ki még más program is ami OpenCL-t használ, nem csak az openoffice. Meg hátha kiderül, hogy jött új driver, amivel hirtelen megtáltosodik, vagy mittudomén.

Én kérek elnézést!

A LibreOffice új verziója nem szimpla OpenCL-t használ, hanem két speckó kiterjesztést. Ez gyorsítja be sokszorosára. Amelyik hardver ezeket nem éri el ott a gyorsulás mértéke nem több pár százaléknál. Sőt, lehet lassulás is, például dedikált GPU-val, vagy olyan konfigurációval, amire nincs Zero Copy.

Azok a kódok, amelyek erre a mély integrációra vannak kihegyezve más OpenCL-es hardveren leginkább lassulást fognak okozni. Esetenként sokszorosat. Erre jön a HSA runtime, hogy a koncepció mindenhol gyorsulást hozzon, anélkül, hogy mindenhova specifikus kódot kellene írni. Az OpenCL-ben viszont nem portolható a teljesítmény.

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

Azok a kódok, amelyek erre a mély integrációra vannak kihegyezve más OpenCL-es hardveren leginkább lassulást fognak okozni. Esetenként sokszorosat. Erre jön a HSA runtime, hogy a koncepció mindenhol gyorsulást hozzon, anélkül, hogy mindenhova specifikus kódot kellene írni. Az OpenCL-ben viszont nem portolható a teljesítmény.

Tehat a HSA runtime megoldja, hogy dgpun is gyorsitson, ellenben opencl-ben nem lehet megoldani? Ezt hogy csinalja?

Egyfelől úgy, hogy teljesen másképp működik a vISA, és a mögöttes réteg, mint bármely mai megoldás. Ebből ered az, hogy bármilyen HSA-ra írt kód teljesítménye portolható minden HSA-t támogató hardvergyártó között. Egyszer megírod és mindig működni fog. Erre lehet még optimalizálni a HSAIL és a gépi kód között. Ez az egyetlen tulajdonsága, ami miatt a szoftveres és a mobil iparág mögé állt.

Ha nincs HSA-t támogató hardvered. Tehát olyan integrációd, ami képes HSAIL kódot futtatni, akkor van a legacy mód. Ez x86-on például AVX2-ig is működni fog. Ha ott van a prociban az ISA, akkor arra optimalizál a HSAIL mögötti réteg.

Azt sajnos nem mondják meg hogy hogyan csinálják a HSAIL mögötti dolgokat. Aki belép a konzorciumba az megtudhatja. A programozó számára elég a HSAIL-t ismerni.

[ Szerkesztve ]

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

Tehat azt mondod, hogy egy olyan feladat, ami cpu-val es dgpu-val opencl-ben nem gyorsul a pcie transzferek miatt az hsa-val ugyanezen a hardveren megis gyorsul?

Nem. A dedikált GPU-ra a HSA nem lesz kiterjesztve. Úgy megoldható a működés, hogy a dedikált GPU HSA módban hagyományos formában nem használhatja a saját memóriáját. Erre valóban lesz is egy implementáció, de mivel senkit sem érdekel a HSA-t támogató cégek közül a hagyományos GPGPU modell, így érdektelen a rendszert ennél jobban fejleszteni ebbe az irányba.
A HSA ott segít, hogy valóban egyszer kell megírnod a kódot, és annak a teljesítménye minden támogató gyártó termékére automatikusan átültethető. Technikailag a HSAIL az az ISA, amit figyelembe kell venni a programozásnál. Utána a többit elintézik a gyártók.

[ Szerkesztve ]

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

Mar csak az nem vilagos, hogy ebben miert lesz jobb a hsa, mint akar az opencl vagy a cuda. Ezek is szerettek volna, hogy a teljesitmeny portolhato legyen, valamennyire mukodik is, de nem 100%-os, a hsa miert lenne ebben jobb?

Mert a HSA-t a nulláról tervezték úgy, hogy a teljesítmény portolható legyen. Ez volt a fő szempont. Nyilvánvaló, ha egy platform fejlesztésénél ezt helyezed előtérbe, akkor más platformokhoz képest, ahol erre nem figyeltek az alapoknál, lényeges előnyt érsz el.

A technikai részleteket azok kapják meg, akik belépnek az alapítványba. A programozó számára elég ha a HSAIL-ig felfedik a rendszer működését. A mögöttes rétegek rejtik a titkokat.

[ Szerkesztve ]

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

Ez nem igy van szerintem, vagy legalabbis csak akkor erheto el, ha a hardverek nem kulonboznek, marpedig azok gyanitom fognak. De ertem, a marketing ezt mondja.

A HSA alapítványban nincs marketinges. Abban van egy vezető ügyvivő, illetve minden cégtől egy magas beosztású mérnök a cégre érvényes szavazati joggal. Ez az alapítvány nem akar marketinggel foglalkozni, mert nem a felhasználókat akarják megcélozni. A usereknek majd a cégek elmondják ahogy akarják. A HSA alapítvány a közös fejlesztésről szól.
Az meg, hogy soha senki sem csinálta még meg nem jelenti azt, hogy kivitelezhetetlen. Az ARM, az AMD és az Imagination eltérő architektúrákkal dolgozik, de mindhárman ugyanazt a kódot futtatják hatékonyan. OpenCL-ben ezt nem tudják megtenni. Ez az oka, hogy a két éve 5 tagból indult HSA alapítványnak ma már 50 tagja van. Megoldást találtak egy égető problémára és ezt megosztják a piaccal.

[ Szerkesztve ]

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

Amikor az opencl drivert irjak, akkor hirtelen teljesen hulyeseget kezdenek csinalni?

Sajnos eléggé különböznek az OpenCL implementációk. Ez nyilván abszolút nem segít a gondokon. És az adott kód teljesítményének portolhatóságán. Egyébként az egyik titok nyilván a HSA implementációjában keresendő. Vannak kötött direktívák, amiket mindenkinek követnie kell. Nagyrészt ez biztosítja, hogy ugyanaz a kód hatékonyan fusson egy teljesen eltérő hardveren.
Ezért van alapítvány, ezért van gyűlés, szavazás, és ezért halad lassan a szabványok elfogadása, mert egyezkednek az implementáció szempontjából. Az Khronos sosem egyezkedik. Mindenki úgy csinálja, ahogy akarja. Nekik csak a működés a fontos, de a sebesség már nem. Azt majd megoldják a program oldalán 2-3-4-5 opcióval.

[ Szerkesztve ]

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

De azert gondold csak vegig, nem teljesen legbolkapott hw-ekrol beszelunk, hanem mondjuk egy amd es egy qualcomm hardverrol. Megirod a kodot, az amugy a hsa meg az opencl eseteben is kb. ugyanugy fog kinezni, es aztan majd mondjuk a hsa eseteben hasonlo sebesseggel fognak menni, az opencl eseteben meg teljesen kulonbozoen? Akkor elcsesztek az opencl drivert nem?

És ki cseszte el az OpenCL drivert? Mert írhatsz olyan kódot, ami x gyártón megy jobban, míg a másik kód y gyártó implementációján. Elkezdhetünk mutogatni, hogy na akkor neki rossz a drivere, de az OpenCL-lel minden rendben, mert a másik gyártó megoldotta, akinek meg máshol nem hatékony a drivere, de az mindegy az OpenCL rendben van, mert mindig tudunk valami pozitív példát felhozni a sok negatív mellé. Persze csinálhatjuk ezt még évekig, vagy lassan felébredünk ebből és megoldjuk a problémát úgy, hogy az a mainstream programozó számára is használható legyen.

(#688) lenox: Elfelejted azt, hogy a HSA-ban mindenki ugyanazt a Queue nyelvet használja, ami az egyik legnagyobb méregfog az OpenCL driverekben. Már ez a különbség is bőven nagyságrendi előrelépést jelent.

[ Szerkesztve ]

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

Azt a reszet nem erted ezek szerint, hogy aki a hsa implementaciojat meg tudja csinalni, az az opencl implementaciojat is meg tudja. Tehat ha az opencl nem skalazodik, akkor szuksegszeruen a hsa sem fog. Ha nem igy lenne, akkor opencl-rol hsail-re forditana valaki a kodot, es maris megoldana, hiszen ugy mar minden jol mukodik, ugye?

nem az implementacioja a lenyeg, hanem a programkod, amit a programozo ir. opencl-re nem fogsz tudni olyan programot irni elagazasok nelkul, ami mindenen jol fut. hsa-val pedig igen. ez uzleti szempontbol segget foldhoz veros oromteli dolog.

A vér nem válik VAZZE!™

Na ne vicceljünk már. Egy OpenCL implementáció nem azért gyors az egyiken és lassú a másikon, mert a driver gyenge az utóbbin! Nagyon gyorsan zökkenjen ki mindenki ebből a téveszméből. Azért lassú, mert ez egy hardverközeli nyelv, és a hardverek mit ad isten különbözőek. ARM Mali-ban nincs shared memória, hanem a globális memóriában van a __shared objektum. Csoda, hogy a Radeonon gemm-ben 2x gyorsulást okozó __shared-be másolás Malin masszívan lassít? Intel GPU-ban nincs vektor típus, Radeonban van. Ezek használata Radeonon gyorsít, másikon meg le se fordul.

HSAIL drivert ugyanúgy akkor meg kell írnia a gyártónak, mint az OpenCL drivert. Innentől pontosan ugyanaz a probléma áll fent, a gyenge driver visszafoghatja a hardvert (és szerintem itt még jobban, mint OpenCL esetében, mert amíg az 1-1 leképezhető hardverfunkciókra vagy egyszerűen nem támogatott a feature, itt a finalizernek rendes fordítást és optimalizálást kell elvégeznie). És ez a lényege a HSAIL-nek: nem te végzed kézzel az optimalizációt a hardverre, hanem a finalizer.

Ami egyébként vicces, hogy egy büdös darab kódrészlet nincs a neten, amit hQ-t demonstrálna, a "HSA hQ sample code" a világ legirrelevánsabb keresési találatokat adó keresések versenyén dobogós lehet..

Az a jo, hogy a HSA-nal nem fordulhat elo, hogy rossz a driver vagy az implementacio. Vagy megis? Mert ugye jelenleg igy nez ki a dolog: OpenCL kernel --> OpenCL-IL fordito --> IL-GPU ISA fordito --> vegrehajtas. Itt el lehet cseszni a 2 lepcsos forditast es lehet nem-tul-optimalisan vegezni a vegrehajtast is. Ezzel szemben, a HSA-nal elso korben lesz egy AMD-fele sajat HSA implementacio, ami igy nez ki: OpenCL kernel (ha mar az OpenCL-rol van szo) --> AMD-fele OpenCL-HSAIL fordito --> AMD-fele HSAIL-GPU ISA fordito --> vegrehajtas. Itt pontosan ugyanannyi lepcsoben lehet elszurni a dolgokat, mint a HSA elotti idokben...

Ha ehelyett lesz majd egy altalanos HSA implementacio, akkor meg igy fog kinezni a dolog: OpenCL kernel --> generalis OpenCL-HSAIL fordito --> AMD/Qualcomm/Samsung/stb-fele HSAIL-GPU ISA fordito --> vegrehajtas. Itt, amennyiben feltetelezzuk azt, hogy a generalis HSAIL fordito hibatlan es gyors kodot is fordit, akkor is megmarad a gyarto sajat HSAIL-GPU ISA forditoja, meg persze a vegrehajtasi resz, ahol ugyanugy el lehet szurni a dolgokat, meghozza nem kicsit, hanem pont annyira, mint a HSA nelkul. Semmi garancia nincs ra, hogy egy HSAIL kodot minden egyes gyartoi implementacio egyforma, egyenletes minosegben fog futtatni az epp aktualis GPU ISA-n. Plusz, azt me'g ki is kell varni, hogy legyen egy igazan jo OpenCL-HSAIL fordito, egyelore me'g az AMD-nek sincs, nem hogy barki masnak...

Mi nem fordul le Intel GPU-n? A float8 peldaul remekul lefordul.

[ Szerkesztve ]

Ez az opencl melyik reszebol kovetkezik? Egy peldan keresztul vilagitsatok mar meg legyszi, hogy ugyanannak a problemanak az opencl kodjat nem lehet ugy megirni, hogy jol fusson, hsail-ben meg igen.

Akkor nem lehet megirni, amikor a ceget (legyen mondjuk az egyik "C" betuvel kezdodo) erosen tamogatja az egyik GPU gyarto Akkor nagyon nehez mas architekturakra portolni az OpenCL kododat, sot, szinte lehetetlen Ha azonban a szoftver keszitojet nem tolja egy gyarto sem, hanem szabadon mokolhat, akkor furcsamod lehet lenyegeben platformfuggetlen OpenCL kodot kesziteni. Oke, lehet hogy lesz benne 1-2 elagazas, de nem tobb szaz, es nem tobb, mint mondjuk egy nativ x86/x64 kodban.

A HSA meg az OpenCL 2.0 egyebkent teny, hogy nagyon jol jon, ha mondjuk SVM-et akar az ember hasznalni. De azert ne allitsuk be ugy, hogy mostantol minden celra tokeletes eszkoz lesz, es az eddigi problemakat egy csapasra elsopri a HSA. Ha igy lenne, akkor mar most egy halom HSA-gyorsitott szoftver lenne piacon, vagy legalabb be lennenek harangozva. Ehhez kepest van 2 db szoftver _keszuloben_, meg egy Windows patch (by AMD), es nagyjabol ennyi.

Nálam HD4000-en semmilyen OpenCL vektor nem fordult le (a CL_DEVICE_NATIVE_VECTOR_WIDTH_FLOAT = 1) Mondjuk azóta jött már ki új SDK, az lehet már tudja.

A nativ csak egy hint, nem szabaly. Es minek SDK? Az OpenCL tamogatas az Intel HD Graphics driver resze.