GPGPU, matematikai számolások a videókártyával

Grafika: GUI, OpenGL

Sziasztok!

Van valakinek a címben emlitett dolgokkal: GPGPU, Nvidia CUDA, Brook, stb. kapcsolatban tapasztalata?

Egy mátrix-mátrix szorzást szeretnék megcsinálni sűrű mátrixokra.
(BLAS: dgemm). Cuda nemnagyon jön szóba, mert egy Geforce 6800-asom
van.

Ha van bátor jelentkező, akkor majd kérdezek ... :)

UDv:axt

  • 6834 megtekintés

( axt v | 2008. 03. 07., p – 12:19 )

Már amikor irtam, gondoltam, hogy nem lesz egy siker-topic ... :)

Lehetőségem van rá, az egésznek annyi a feltétele, hogy tudjon a videokártya float típusú textúrákat,
amit a 6800 tud.

Amire te gondolsz, az az, hogy az Nvidia CUDA, cuBLAS, stb korlátozódik a 8x szériára.
Egyébként a CUDA nagyon tetszetős keretrendszer, de nem szeretnék új videókártyát és
emiatt új alaplapot (PCI-Express miatt), stb venni.

( Andrei | 2008. 03. 07., p – 13:58 )

Ha a dgemm-et akarod kivaltani, akkor cserelned kell, mert csak az iden megjeleno kartyak fognak tudni dupla lebegopontos szamitasokat. Amennyiben az SGEMM is jo, akkor meg mindig kerdeses a vegeredmeny. Amennyire en emlekszem, n=1000 kornyeken kezd el gyorsabb lenni a videokartya, addig az adatok fel- es letoltese miatti kesleltetes elfedi teljesitmeny javulasat.

A dgemm végülis typo volt, jó lenne simán floatra is az eredmény. Gondolom amit írsz, hogy n=1000 az négyzetes mátrixra vonatkozik ...

Nekem elvben 100.000x100-as matrixokat kene szoroztassak 100x100-as matrixokkal. Ha jol vettem ki a doksikból a videókártyám max 4096x4096-os float texturákat tud, azaz vsz 4096x100-as matrixot kene 100x100-assal szoroznom, (100.000/4096)-szor egy adott lepeshez. Csak felek tole, hogy nem tudok belole jobbat kihozni a CPU-GPU transferek költsége miatt.

Dimenzióredukció (ami SVD-vel (singular value decomposition) van megoldva )gyorsitása a cél. A bemenő mátrix úgy áll össze, hogy: 


[video_frame:t  ][video_frame_t+1] ... [video_frame_t+n  ]
[video_frame:t+1][video_frame_t+1] ... [video_frame_t+n+1]
...

vagy 


[video_frame:t  ]
[video_frame:t+1]
[video_frame:t+2]
...

ahol a video_frame egy videó vagy annak egy tartományának reprezentációja egy vektorral :-)

koszi az infokat, igazából ilyen benchmark eredményekre volnék kivancsi ...

jó lenne, ha lenne egy oldal, ahol ezek le vannak irva, de sajnos még nem találtam

gondolom te is kimérted. arra megkérhetnélek, hogy ugyanekkora mátrixra, megmérnéd
nekem az atlas dgemm mennyi idő alatt fut le. csak viszonyításképp ...

Amivel szamolnod kell az ugye a matrix meretenek es az elvegzendo muveleteknek az aranya.

Mivel a matrix meret (es ezzel a GPU-ba toltes koltsege) negyzetesen novekszik, a muveletek (tipikusan szorzasok) szama pedig kobosen ezert valami durva okolszabalyt fel lehet allitani.

n=1000 eseten a matrix merete (32 bit float): 8000000 byte (ket operandussal szamolva)
a szukseges muveletek szama: 1000000000 op

Szoval, ha az algoritmusod 125-nel jobb op/byte mutatoval rendelkezik, akkor nem vagy rossz. Persze ez a 125 adott CPU-GPU parositastol fuggoen valtozhat. Igy neked kell a sajat konfigodra kimerni....

köszi az infót. elsőkörben úgy gondoltam, hogy csak akkor állok neki az egész GPU dolognak, ha biztos vagyok benne, hogy megéri. sajnos elég zöldfülű vagyok a GPU programozásához, és nem akarnék most sok energiát belefektetni. ez a 125 milyen hardware-en jött ki neked? hátha közel van ahhoz amit én akarok használni :)

( strangelove | 2008. 03. 07., p – 19:04 )

mhmmm...
kíváncsi vagyok, ritka/n-reguláris mátrixokon történő pivotálást hogyan tudná egy GPU jól és hatékonyan kezelni, b&b-t parallel módon...
ami át van húzva, azt teljesen fölösleges elolvasni. az olyan, mintha ott sem lenne

Hatekonyan valszeg sehogy... Valamennyit supernode-ok bevezetesevel lehet rajta gyogyitani. A ritka matrix algoritmusok eleg sok indirekciot es elagazast tartalmaznak, a GPU ezekben nagyon rossz. Nem kizart, hogy sikerul javitani rajta, de nagysagrendi speedupot nem erdemes varni.

( axt v | 2008. 03. 08., szo – 10:19 )

Koszonom mindenkinek a valaszokat! Annyi lenne még a kérdésem, hogy amennyiben mégis GPU programozásra adnám a fejem, milyen keretrendszert használjak, ha az nvidia cuda (ami tetszik:)) nem jöhet szóba, mert nem 8xxx-es a kártyám. Egyaltalan erdemes e keretrendszert használni?

( turul16 v | 2008. 03. 08., szo – 10:39 )

nvdia 8xxx -hez van egy ujfajta FEED BACK lehetoseg opengl -el. elfelejtettem a nevet :( ,azzal lehet szamitasi adatokat jol kicsalni.
Regebinel marad a sima feedback buffer -es megoldas.

Az sh-t már nem fejlesztik...
RapidMind Development Platform lett belőle, de az meg már kicsit más (GPU, CELL, multicore támogatás egyben).

A Brook-ot meg az ati/amd pénzeli újabban, CTM támogatás stb.

Hosszú távon neked csak a CUDA marad...

Rövidtávon meg amelyik kényelmesebb a tutorialok alapján...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

( axt v | 2009. 07. 20., h – 19:25 )

Nem akartam új topicot nyitni!

Azóta hozzájutottam egy géphez amiben CUDA kompatibilis videókártya van, és át is írtam az inkrementális SVD algoritmust GPU+CPU párosra [bár már nincs rá szükségem :-)].

A kérdésem most az lenne, hogy tudtok-e esetleg valami teljesítmény összehasonlítást a videókártyák közt. Perpill egy nvidia 9400M -em van ami, amint a nevéből is fakad mobil verzió. Az érdekelne, hogy ehhez képest hogyan teljesít valami komolyabb (9800 GTX, vagy G280) darab kártya.

[Egyébként a jelenlegi eredmény az az, hogy egy Core2 Duo P7350 (2.00GHz) procinál 2-3x gyorsabb a videókártyás implementáció (a transzfer időkkel együtt). A procin futó gsl+BLAS-t használ.]

NVidia fórumain már láttam, hogy többen lefuttattak egy-egy demót az sdk-ból, és a benchmark eredményeket leközölték a kártyáik paramétereivel együtt.
Ez persze nem feltétlenül ad neked információt arról, hogy a te programod hogyan futna egy jobb kártyán.

Ha rájössz, hogy az algoritmusod szűk keresztmetszete micsoda (memóriasebesség vagy számítási egység) akkor a kártyák hw specifikációjából elég jól lehet következtetni a várható sebességre, mert ált. elég jól (közel lineárisan) skálázódik.

Másik megoldás, hogy megkérsz másokat (pl az nvidia fórumon), hogy fordítsák le, és futtassák a kódodat. Egy svd elég veszélytelennek tűnik ahhoz, hogy megtegyék. :)

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

(pontosan;
de annak aki csak *kb* szeretné, tehát ha pl az említett lineáris/ideális eset áll fenn, tudni:
- a 9400 csak a 2. legrosszabb, de ettől is a leggyorsabb csak 15x gyorsabb, tartalmaz több procit ([98]300 és attól lefele már csak 1db multiprocesszor (8db proc) van, 9400:2db, gtx280:30db )
- ezen kívül még 2x-est rátesz amelyikben 2 gpu van, ugyanígy kártyaszám :)
- ill. még egy hangyányit rátesz a mhz-beli különbség (pl hogy mobil nem sokat sokat számít az 1. ponthoz képest)

ha pedig nem ugyanazt a kódot nézzük, a legújabbakban már 1.3-as (nem 1.1-es) cuda-beli compute capability van, ez hozhat lényeges gyorsulást
)