[CUDA] Ervarigen met CUDA *

[Matis]

Beste allemaal,

ik ben sinds een aantal dagen bezig met het programmeren in CUDA. IK heb hier mijn eerste kennis vergaard mbt CUDA en de "programmeertaal".

Gezien het feit dat ik Ubuntu 8.10 draai en NVidia (nog) geen downloads heeft voor 8.10 heb ik deze tutorial gevolgd voor het installeren van alle drivers en SDK's op 8.10. Hierin wordt keurig beschreven hoe dat je CUDA moet installeren (wel op 8.04), Eclipse moet instellen en een nog meer tips.

Ik wil graag dit topic openen zodat iedereen die CUDA ervaring heeft of wil gaan verkrijgen elkaar kunnen helpen en met het delen van source code anderen op een idee kunnen brengen voor eigen ontwikkeling.

Je hardware checken:

code:

mathijs@mathijs-desktop:~$ ./NVIDIA_CUDA_SDK/bin/linux/release/deviceQuery

There is 1 device supporting CUDA

Device 0: "GeForce 9800 GTX+"
  Major revision number:                         1
  Minor revision number:                         1
  Total amount of global memory:                 536150016 bytes
  Number of multiprocessors:                     16
  Number of cores:                               128
  Total amount of constant memory:               65536 bytes
  Total amount of shared memory per block:       16384 bytes
  Total number of registers available per block: 8192
  Warp size:                                     32
  Maximum number of threads per block:           512
  Maximum sizes of each dimension of a block:    512 x 512 x 64
  Maximum sizes of each dimension of a grid:     65535 x 65535 x 1
  Maximum memory pitch:                          262144 bytes
  Texture alignment:                             256 bytes
  Clock rate:                                    1.84 GHz
  Concurrent copy and execution:                 Yes

Test PASSED

Press ENTER to exit...

Het is natuurlijk helemaal afhankelijk van je hardware wat voor terugkoppeling je krijgt

Hier kun je nog wat voorbeelden vinden van CUDA projectjes.

[ Voor 56% gewijzigd door Matis op 23-02-2009 10:04 . Reden: Extra tekst, Typo's ]

[Creepy]

Ervaringen delen over CUDA is natuurlijk prima maar gezien Invulling en behandeling Grote Topics aangepast is het niet de bedoeling om hier even snel een vraagje te stellen om een probleem gefixt te krijgen. Dat soort zaken moeten gewoon ineen eigen topic.

[Matis]

Creepy schreef op maandag 23 februari 2009 @ 10:34:
Ervaringen delen over CUDA is natuurlijk prima maar gezien Invulling en behandeling Grote Topics aangepast is het niet de bedoeling om hier even snel een vraagje te stellen om een probleem gefixt te krijgen. Dat soort zaken moeten gewoon ineen eigen topic.

Owkee, sorry My Bad Ik wilde gewoon een soort van Grote Ervaringen met CUDA deel 1 starten. Gewoon omdat het een revolutionair systeem is en ik er op GoT niet heel veel over kon vinden.

De moderators zullen dus vanaf nu topics die onder deze beleidswijziging vallen sluiten. In plaats van een zojuist gesloten verzameltopic mag je natuurlijk een nieuw ervaringentopic openen, als je denkt dat hier behoefte aan is. Als een dergelijk topic een mooie topicstart krijgt met veel informatie wordt dat natuurlijk nog steeds op prijs gesteld. Overleg wel eerst even, bijvoorbeeld via Schop een Modje, voor je zo'n nieuw topic opent.

Bij deze

[ Voor 28% gewijzigd door Matis op 23-02-2009 10:51 ]

[Soultaker]

Ik ben wel geïnteresseerd in het gebruik van/praktische ervaringen met CUDA, maar zelf zal ik bij gebrek aan voldoende high-end hardware niet veel toe te voegen hebben, helaas.

[Zoijar]

Ik heb wel redelijk veel ervaring met CUDA, maar ja, wat valt er verder over te melden... Ik weet niet hoe lang CUDA nog het leven heeft; volgens mij is de trend om alles om te zetten naar OpenCL (note, niet OpenGL ) begonnen. ik dacht dat nvidia daar ook in mee ging...

[ Voor 4% gewijzigd door Zoijar op 23-02-2009 20:41 ]

[Matis]

Zoijar schreef op maandag 23 februari 2009 @ 20:40:
Ik heb wel redelijk veel ervaring met CUDA, maar ja, wat valt er verder over te melden... Ik weet niet hoe lang CUDA nog het leven heeft; volgens mij is de trend om alles om te zetten naar OpenCL (note, niet OpenGL ) begonnen. ik dacht dat nvidia daar ook in mee ging...

Klopt, alleen is openCL nogal nieuw en de community is nog niet groot voor openCL en ook nog weinig voorbeelden.

Ik zie idd openCL als een nieuwe trend voor GPU-computing. Nvidia en Ati zijn het nu aan het implementeren in de drivers en sdk's enzo.

[ATS]

Het probleem van OpenCL is, voor zover ik kon vinden, dat het er erg leuk uit ziet, maar dat er nog geen bruikbare implementaties zijn.
Ik heb op mijn werk net een nieuw systeem waarmee we ook CUDA willen gaan gebruiken (met een dikke Nvidia Quattro kaart erin), maar ik ben er nog niet aan toe gekomen om eraan te beginnen helaas. De techniek ziet er leuk uit, hoewel het nog wel lijkt dat je, als je de prestaties een beetje wil optimaliseren voor jouw systeem, je toch nog aardig moet tweaken aan de verdeling van je werk. Dat is jammer, omdat elk systeem natuurlijk weer andere parameters heeft (meer/minder geheugen, meer/minder 'cores', etc.).

[Zoijar]

Ik ben altijd vooral geinteresseerd in multi-gpu oplossingen. Met CUDA gaat dat heel makkelijk; je kan gewoon devices openen los van elkaar, of je kan ze samen laten werken. Klassieke openGL drivers hebben daar nogal wat problemen mee. Zo draait in mijn ervaring en programma dat twee threads gebruikt met verschillende opengl contexts op verschillende GPUs alsnog maar op de snelheid van 1 GPU. Met CUDA gaat het gewoon 2x zo snel. (2 processes kan dan weer wel op 2x speed, maar niet op windows...)

Ik heb wel vertrouwen in OpenCL hoor. Nog even wachten alleen. Het wordt gecontroleerd door de khronos group, dat zijn de mensen die nu ook OpenGL in handen hebben (toch niet de minste API) met support van Apple, Nvidia en Ati (toch ook niet de minste vendors )

[ Voor 28% gewijzigd door Zoijar op 25-02-2009 10:20 ]

[roy-t]

Zoijar schreef op woensdag 25 februari 2009 @ 10:13:
Ik heb wel vertrouwen in OpenCL hoor. Nog even wachten alleen. Het wordt gecontroleerd door de khronos group, dat zijn de mensen die nu ook OpenGL in handen hebben (toch niet de minste API) met support van Apple, Nvidia en Ati (toch ook niet de minste vendors )

Daar maak ik me nu juist weer zorgen om, Khronos is niet erg goed in 1 lijn kiezen of uberhaupt tactische beslissingen te maken en blijven altijd maar een beetje hangen in het "ach werkt wel" stadium. (Tenminste zo zie ik de nieuweste versie van OpenGL en het debat/debakel daar over).

Maar aangezien OpenCL nieuw is zou het goed kunnen gaan, als maar niet al die grote vendors gaan op hun strepen gaan staan, maar er gewoon 1 duidelijke lijn invullen.

Was MS trouwens niet bezig met een soort van DirectX achtige GPGPU implementatie? MS maakt over het algemeen erg mooie API's dus ik ben daar ook erg benieuwd naar.

Ah, meer info over GPGPU/DX11: http://news.softpedia.com...PU-Revolution-91539.shtml

[Zoijar]

roy-t schreef op woensdag 25 februari 2009 @ 11:17:
Daar maak ik me nu juist weer zorgen om, Khronos is niet erg goed in 1 lijn kiezen of uberhaupt tactische beslissingen te maken en blijven altijd maar een beetje hangen in het "ach werkt wel" stadium. (Tenminste zo zie ik de nieuweste versie van OpenGL en het debat/debakel daar over).

OpenGL aanpassen is altijd lastig omdat er zo veel legacy applicaties op draaien. Er is in ieder geval een stap gemaakt met een nieuwe 3.0 context die niet backwards compatible is, en de fixed functionality is deprecated (maar zal nooit verdwijnen).

Maar aangezien OpenCL nieuw is zou het goed kunnen gaan, als maar niet al die grote vendors gaan op hun strepen gaan staan, maar er gewoon 1 duidelijke lijn invullen.

Het is wel handig als het in een lijn met de hardware is, dan is het meteen bruikbaar. Maar wie weet wordt de hardware ook iets aangepast om het een meer gestroomlijnd geheel te maken; ik hoop het ook.

Was MS trouwens niet bezig met een soort van DirectX achtige GPGPU implementatie? MS maakt over het algemeen erg mooie API's dus ik ben daar ook erg benieuwd naar.

Ah, meer info over GPGPU/DX11: http://news.softpedia.com...PU-Revolution-91539.shtml

Tsja, MS zal niet z'n eigen standaard willen introduceren Ik denk toch dat een computing platform voornamelijk van belang is voor een doelgroep die veelal op opengl draait op het moment.

[jvaneijk]

Oke even mijn ervaring:

Ik heb september 2007 voor het eerst kennis gemaakt met CUDA. Ik heb CUDA gebruikt tijdens een Project in het Academisch Medisch Centrum (AMC) in Amsterdam. Ik heb CUDA gebruikt voor het snel berekenen van de Radiological Depth en alles wat daarbij komt kijken. Om zo een redelijke stap te doen naar Interactieve Dosesberekeningen.

Dit is nu allemaal redelijk op poten gezet en hebben er een publicatie (Accelerated ray-tracing for radiotherapy dose calculations on a GPU) over ingediend bij het blad Medical Physics, nu alleen nog even afwachten wanneer het wordt gepubliceerd.

Wat betreft mijn ervaring omtrent CUDA.. Ik heb het als een van de eerste gebruikers zeer fijn ervaren. Enige problemen waren er nog wel met bugs. Maar omdat er nog zo weinig gebruikers waren hadden we redelijk goed contact met de ontwikkelaars van CUDA zelf zodat we snel te horen kregen hoe we bepaalde dingen konden oplossen...

Heb je een onderdeel dat goed geparalelliseerd kan worden gebruik CUDA mits je een Nvidia kaart hebt met een chipset die minimaal G80 is

HULDE voor NVIDIA!!!

[jvaneijk]

ATS schreef op woensdag 25 februari 2009 @ 08:08:
Het probleem van OpenCL is, voor zover ik kon vinden, dat het er erg leuk uit ziet, maar dat er nog geen bruikbare implementaties zijn.
Ik heb op mijn werk net een nieuw systeem waarmee we ook CUDA willen gaan gebruiken (met een dikke Nvidia Quattro kaart erin), maar ik ben er nog niet aan toe gekomen om eraan te beginnen helaas. De techniek ziet er leuk uit, hoewel het nog wel lijkt dat je, als je de prestaties een beetje wil optimaliseren voor jouw systeem, je toch nog aardig moet tweaken aan de verdeling van je werk. Dat is jammer, omdat elk systeem natuurlijk weer andere parameters heeft (meer/minder geheugen, meer/minder 'cores', etc.).

Dit geldt met iedere vorm van GPU computing. Ook voor CUDA, ATI CTM of Rapidmind. En dan is het ook nog helemaal afhankelijk hoe je je blokken onderverdeeld voor je probleem.. Dit is een tweaking stap die echt het meeste tijd in beslag neemt. Het gewoon programmeren is niet zo'n probleem maar tweaken is moeilijk. Maar daar haal je wel de dikke winst uit... En probeer het op een computer die een dedicated kaart erin heeft zoals een Tesla om zo echt snel te kunnen zijn zonder dat je je moet afvragen hoeveel videogeheugen je Windows of Linux opsnoept (Kan namelijk erg frustrerend zijn)

[jvaneijk]

Zoijar schreef op woensdag 25 februari 2009 @ 10:13:
Ik ben altijd vooral geinteresseerd in multi-gpu oplossingen. Met CUDA gaat dat heel makkelijk; je kan gewoon devices openen los van elkaar, of je kan ze samen laten werken. Klassieke openGL drivers hebben daar nogal wat problemen mee. Zo draait in mijn ervaring en programma dat twee threads gebruikt met verschillende opengl contexts op verschillende GPUs alsnog maar op de snelheid van 1 GPU. Met CUDA gaat het gewoon 2x zo snel. (2 processes kan dan weer wel op 2x speed, maar niet op windows...)

Ik heb wel vertrouwen in OpenCL hoor. Nog even wachten alleen. Het wordt gecontroleerd door de khronos group, dat zijn de mensen die nu ook OpenGL in handen hebben (toch niet de minste API) met support van Apple, Nvidia en Ati (toch ook niet de minste vendors )

Mag een mooie techniek zijn dat OpenCL maar het mooie dat je juist hebt met CUDA of CTM ten opzichten van OpenGL of DirectX is dat je die overhead niet hebt. Wat betreft OpenCL weet ik het niet of dat overhead heeft maar OpenGL en DX wel ontzettend en de leercurve is ontzettend hoog voor OpenGL en DX. En met CTM en CUDA is het relatief laag, omdat het gewoon een Extensie is op C/C++

[Creepy]

offtopic:
Ik heb wat posts verwijderd gezien [CUDA] Globaal geheugen GPU *

[Zoijar]

jvaneijk schreef op donderdag 26 februari 2009 @ 13:41:
[...]


Mag een mooie techniek zijn dat OpenCL maar het mooie dat je juist hebt met CUDA of CTM ten opzichten van OpenGL of DirectX is dat je die overhead niet hebt. Wat betreft OpenCL weet ik het niet of dat overhead heeft maar OpenGL en DX wel ontzettend en de leercurve is ontzettend hoog voor OpenGL en DX. En met CTM en CUDA is het relatief laag, omdat het gewoon een Extensie is op C/C++

Daar kan ik het alleen maar mee eens zijn; klassiek GPGPU programmeren op OpenGL is... time-consuming

Overigens wel een minpuntje voor CUDA: al sinds de eerste beta versie hebben ik en andere uiteraard er over geklaagd dat cudaGLMapBufferObject() te traag is. Dat is de enige manier om normaal gesproken data van CUDA naar een OpenGL renderer te krijgen; iets dat je toch vaak wilt doen als je data ook wilt afbeelden. Maar die map functie is een bottleneck. Het is zelfs sneller om alle data eerst naar je host te downloaden, en dan opnieuw naar opengl te uploaden. Het effect is dat je slechts iets van 0.5 a 1 GB/s oid haalt op een moderne kaart om CUDA geheugen naar OpenGL geheugen te krijgen. Terwijl je device dat zeker boven de 60GB/s rechtstreeks zou kunnen. Misschien is het inmiddels opgelost, maar 2.0 beta deed het nog steeds slecht...

(Dat is trouwens een rede dat ik nog heel veel op de oude manier met shaders in OpenGL doe. Dingen die ik liever in CUDA zou doen, maar dan gewoon te traag zijn.)

[ Voor 5% gewijzigd door Zoijar op 26-02-2009 20:38 ]

[jvaneijk]

Ja.. Ik heb zelf niets gedaan met beeldbewerking / OpenGL in combinatie met CUDA gelukkig. Ik ben niet van de grafische shit. Ik gebruik dat ding om super snel dezelfde berekening uit te voeren en voor de rest mag hij de pot op

Daarom zijn die Tesla's ook zo ontzettend mooi die hebben niet eens een aansluiting voor een monitor.. Niet gezegd dat hij niets kan renderen want dat kan dat ding wel degelijk hij stuurt alleen geen monitor aan..