koszonom szepen, a hibat javitottam..
maga a szabvany a float-ot koveteli meg, de az OpenCL-ben is (mint OpenGL-ben) vannak extension-ok, es letezik double preciosion extension.. tehat igazabol hardverfuggo a dolog, nekem pl. a videokartyam (FX570m) nem tamogatja ezt a kiegeszitot, a procim meg igen (meg jo )..

masik kerdesedre is az a valaszom, hogy implementacio-fuggo.. OCL csak egy szabvany, az, hogy ezt hogyan valositjak meg a hardvergyartok a sajat architekturajukra, teljesen rajtuk mulik.. eddig csak nVidia kartyara programoztam, ott nem lehet gond az 5-10 megabajt meretu buffer.. pl a saxpy-s peldaprogi 25165824-es vektormerettel is tok jol mukodik.. ez ugye ket darab 96 megas vektort jelent (egy olyan kartyaval, amin csak 256 mega memo van)..

in asm we trust

Kösz a választ.
Legszívesebben már most átportolnám a project-et. A float végülis nem nagy érvágás, szerintem még mindig elég pontosságú lenne a number crunching. Ez biztató, hogy 96 megás vektort is vitt a cucc. Mondjuk elvégre is ha ilyen tudományos számításokra gondolunk (márpedig a GPGPU megoldások erre jók), akkor értelemszerűen felmerül a nagy mennyiségű adatok kérdése. Látom, hogy mi a veszélye annak, hogy a nagy vektorok lekezelése hardver/driver függő, de elvárom, hogy működjön. Ugye az API mögött nekik kell megoldani transzparens módon az adatok kisebb méretre darabolását, ha túl nagyok.

Mostmár csak várni kell 1-2 évet, hogy kijöjjön az ATI és az nVidia is driverekkel meg kiforrjon kicsit a cucc, meg kell egy olyan Quadro-s laptop, ami neked van, aztán prezentálni tudnék a megrendelőnek egy OpenCL-es verziót.

Acer Predator Helios 500 Ryzen, Samsung 960 Pro NVMe + GeChic 15.6" kulso monitor a mobil irodahoz

lehet, hogy felreerthetoen fogalmaztan.. azt, hogy nagy vektorok kezelese hardverfuggo, nem ugy ertettem, hogy a driver feladata egy nagy buffert szetbontani kezelheto darabokra.. annyit akartam vele mondani, hogy minden hardver kulonbozo mennyisegu memoriaval rendelkezik, es hogy egy adott architektura akar lehet olyan is, hogy nem tud nagy bufferekkel optimalisan dolgozni (nem tudom, hogy van-e ilyen, de ki tudja)..

gyakorlatilag ez ugy nez ki, hogy az eszkozon elerheto valamilyen mennyisegu globalis, konstans, lokalis, es privat memoria.. ezeket az adatokat az OCL runtime-tol le lehet kerdezni.. ezek, es az alkalmazas memoriaigenyenek tudataban neked kell beosztanod, hogy hogyan gazdalkodsz a memoval.. nagyon nagy adatok eseten mondjuk egy kezelheto darabra lefuttatod a kernelt, visszaolvasod az eredmenyt, aztan futtatod megint a kernelt egy masik adatdarabon, es igy tovabb..

1-2 evet talan nem kell varni, beta driverek mar most is vannak.. ATI vonalon nem tudom, mi a helyzet, de nVidia-ek ugye a CUDA architekturara epitettek az OpenCL implementaciojukat, az meg mar eleg kiforrott..
ja, es ebben a Quadro-ban az a 256 mega/32 stream proci kombo keves tud lenni neha, akkor mar inkabb valami 512MB-os FX770m/HD3650, vagy hasonlo

in asm we trust

Köszi a választ.
Akkor a te általad említett 96MB-os vektoros példában te magad gondoskodtál valami kóddal ennek a feldarabolásáról? Lehetőleg én nem szeretnék ezzel foglalkozni, mert hw függő. Persze írható hw független kód a darabolásra, de elvárnám, hogy a drvier/OpenCL architektúra ezt megtegye.

Acer Predator Helios 500 Ryzen, Samsung 960 Pro NVMe + GeChic 15.6" kulso monitor a mobil irodahoz

Még egy kérdés. Ugyan követtem a CUDA és egyéb technológiák megjelenését, de mély ismereteim nincsenek még. Talán te kapásból tudod a választ.
Az általam portolandó tudományos számítás extenzíven használ exponenciális függvényeket. Az architektúra támogat exponenciális vagy logaritmikus lebegőpontos műveleteket is? Igazából itt most egy kicsit elkezdtem félni is, mert valószínűleg a GPU-ban levő floating-point egységek nem erre vannak kihegyezve/optimalizálva.

Acer Predator Helios 500 Ryzen, Samsung 960 Pro NVMe + GeChic 15.6" kulso monitor a mobil irodahoz

nincs mit..
az FX570m 256 megajanak nagy resze felhasznalhato globalis memoriakent (nem az egesz, mert ugye ott van meg a kepernyobuffer, konstans memoria, stb. is), igy felfert egyben a ket darab 96 megas vektor a kartyara.. azert ha vesz az ember ilyen 1-2 giga memoval rendelkezo kartyakat, azokon mar jol el lehet ferni..

exp-et, log-ot megkoveteli a szabvany, tehat az OCL-t tudo hardverek tudjak..

[ Szerkesztve ]

in asm we trust

2 napja letölthető NVidia driver OpenCL-hez: [link]

Nagyon jó a cikk, már egyébként is foglalkoztatott a dolog, valamint a diplomamunkámhoz is kelleni fog. Amint lesz időm meló és suli mellett rögtön alkotok valamit

Feldobta ez a cikk a napom.

[ Szerkesztve ]

"Welcome to the real world"

Nekem is feldobta anno a napom. Egyre izgatottabb vagyok, nem birok varni, hogy ne probaljam ki. Kene egy jo hardver (oke, elvileg csak CPU-t is kezel az OpenCL).

Mirol szol a diplomamunkad?

Acer Predator Helios 500 Ryzen, Samsung 960 Pro NVMe + GeChic 15.6" kulso monitor a mobil irodahoz

Ha asztalid van akkor egy 9600GT-t belehet szerezni 20Ft környékén már simán. Nekem is az van. 9600GT-t használom koprocesszornak 3DMark Vantage-ban így a procim 10000 helyett 21000 pontot kapott!

Törések szimulálásáról a grafikában és ezt gpu-n akarom számoltatni, dióhéjban erről szól a diploma munkám.

Egyébként érdekes lesz ez az openCL-s dolog, ugyanis ma szórakoztam a dologgal egy kicsit.

Feltettem Ati Stream sdk-t és az NVidia-s NBody projektet nem sikerült az Ati -s opencl.dll -l műküödésre bírni (újra fordítottam a projektet és az Ati-s headereket valamint librarykat használtam, majd az Ati-s opencl.dll -t ette meg). Valami felszabadító függvény még nem került bele az AMD-s opencl dll-be. Mellesleg a Stream SDK 2.0 beta-ban jelenleg még csak CPU támogatás van.

"Welcome to the real world"

Egy kis javítás a cikkhez:
a parameter cannot be allocated in a named address space -t dob a clBuildProgram ha az "a" paramétert nem __private címtérbe kerül ( ATI Stream SDK-ban, NVidia sdk alatt megy a dolog )

Utána olvastam az OpenCL doksiban (Khronos_OpenCL_Specification.pdf 149 oldal ) és azt írják, hogy a __kernel függvények bemenő paramétereinek mindnek __private address space-ben kell lennie, viszont ha pointer a bemenő paraméter az lehet __global, __constant, __local és a címterek közti castolás nem lehetséges.

Tehát a példa progi jól megy NVidia sdk-val viszont Ati sdk-val nem.

Kérdés: tud valaki valami olyan eszközt amivel jól lehet profilozni a futó kódot?

"Welcome to the real world"

jogos, koszonom rogton javitom...
meg ha mar szoba jottek az address space-ek, talan erdemes megemliteni, hogy az x lehetne __constant, mert ugysem valtozik az erteke, es a konstans memo cache-elve van (legalabbis CUDA architekturan)..

nVidia-nak Win-re es Linux-ra van egy OpenCL Visual Profiler nevu cucca, bar meg csak beta..

in asm we trust

javitottam.. meg a peldaprogiban volt egy masik csunya bug is: az eredmeny ellenorzesekor abs-ot hasznaltam fabs helyett, igy egy esetleges hibas szamolas utan is azt kaptuk volna, hogy 1000-bol 1000 sikerult

karicska: esetleg megprobalnad a peldaprogit forditani/futtatni ugy, hogy a 147. sornal kezdodo kommentezett blokkot is beleforditod? OSX-en nem akar mukodni, nem tudom miert.

// es meg valami, ami nagyon off: ismeros volt a nick-ed, rakerestem az e-mail cimedre, latom ELTE-s vagy.. veletlenul nem a nagytetenyi uti koliban laksz? van itt a halon egy gep karics-pc, vagy valami hasonlo nevvel, ez elegge hasonlit a karicska-hoz ..

in asm we trust

Most megyek el, de amikor vissza jöttem lefordítom és megnézem.

[OFF]de-de az az én gépem lesz

Amikor még csináltam ide az accot akkor még karicska voltam, azóta felnőtem és karics lettem [/OFF]

"Welcome to the real world"

Piszkálta a fantáziám a dolog, úgyhog megnéztem, de nem nyert, röpke 102 error + 45 warninggal fordult :S

Az első hiba: error C2275: 'cl_platform_id' : illegal use of this type as an expression

Visszaérek este valamikor aztán megnézem pontosan.

Az én kódom eddig tök ugyanez (van egy két kiiratás de az nem zavar be ) és nekem lefordul. Ugyanabba a környezetbe raktam be, amiben az enyém van. Még dolgozom este rajta.

"Welcome to the real world"

Már lefordul és fut is

NVidia SDK: ha a bináris fájl betöltést kikommentezem akkor semmi gond.

ATI Stream SDK 2.0 beta3: ha kikommentezem a bináris fájl betöltést akkor problémázik a program végén, hogy a binary változó nem ment át a run-time checken. Nem láttam még életemben ezt a hibaüzenetet.

Este ha visszaértem utána járok. Már így is 1 órával többet foglalkoztam vele, mint kellett volna

"Welcome to the real world"

sry, hogy csak most valaszolok, kicsit el voltam havazva..

kosz, hogy kiprobaltad a progit!
otthon en is ki akartam probalni win alatt.. 64 bites Win7-re nem ment az OpenCL SDK (azt mondja, legalabb XP kell neki.. fura, mert OpenCL driver meg van Win7-re).. az Ati SDK-val meg meg nem volt idom foglalkozni.. talan a heten..

"de-de az az én gépem lesz"
na, akkor jol sejtettem

in asm we trust

kijott az Ati Stream SDK 2.0-beta4, mukodik vele a GPU gyorsitas.. meg tamogatja a 64 bites Windows-okat, koztuk a Win7-et is.. [link]

[ Szerkesztve ]

in asm we trust

Tök jó!

Akkor mostmár ezt teszem fel nem a régit. (Most telepítettem új windows-t (Win 7 64bit ).

Egyébként nekem előtte is win7-m volt csak beta, és azon minden ment.

"Welcome to the real world"