[ALG] Ervaringen GPGPU

[jvaneijk]

Beste tweakers,

Ik ben zeer benieuwd naar jullie ervaringen met GPGPU.
Voor de mensen die niet weten wat GPGPU is of er juist erg geinstresseerd in zijn hieronder een link naar een website die je alles kan vertellen:
http://www.gpgpu.org

Zelf wil ik heel erg graag werken met GPGPU, maar ben er nog niet over uit welke API / Toolkit ik ga nemen. Zit momenteel nog erg te twijvelen tussen Nvidia's CUDA en Rapidmind

Zou graag een leuke discussie hierover op gang willen brengen, aangezien de laatste die ik terug vond uit 2004 afkomstig is ofzo, lijkt het me wel weer eens tijd om dit mooie concept aan te halen.

Het is per slot van rekening de toekomst in mijn ogen (vervanging van de supercomputer)
Nieuwe Tesla opstelling de S870 (http://www.nvidia.com/object/tesla_gpu_server.html) heeft een peak floating point performance van meer dan 2TFlops
in vergelijking met de nieuwe supercomputer van SARA (14,6TFlops) zie link hieronder:
https://subtrac.sara.nl/userdoc/wiki/huygens/description
Het kleine verschil is dat SARA het voor elkaar krijgt met 960 Dual core processors en Nvidia maar met 4 GPUs (als je ze zo mag noemen), ziet er dus erg veelbelovend uit.
Niet vergeten de Nvidia Tesla server kost maar 12000,- dollar in vergelijking tot de IBM supercomputer???

Gegroet.

[jvaneijk]

Even een trapje, Er zijn toch wel mensen die GPGPU gebruiken of geinteresseerd hierin zijn?

[Oguz286]

Ik was eerst van plan om nVidia's CUDA te gebruiken (en de reden waarom ik een 8800GTS wilde) maar een vriend liet me laatst rapidmind zien. Aangezien ik een Q6600 heb en een redelijk snelle grafische kaart wil aanschaffen en het ook op een PS3 werkt neig ik nu meer naar rapidmind. Alleen ervaring heb ik niet echt.

We kwamen op het idee om een van deze toolkits te gebruiken omdat we tijdens lineare algebra college's besloten raytracers te gaan schrijven. Ik schreef het gewoon in VC++ single-threaded en die vriend op zijn 8800GTS icm CUDA. Nou dat loopt toch echt een heel stuk sneller Nu de raytracer steeds uitgebreider begint te worden, wordt de vraag naar rekenkracht een stuk groter dus vandaar Echt ervaring heb ik dus nog niet maar dat gaat hopelijk binnenkort komen.

[The Flying Dutchman]

Ik sta op het punt om te beginnen met gpu programming. Als je leuke dingen wilt (realistisch ogende natuurkundige berekeningen bijvoorbeeld) programmeren als hobbyist, dan is de gpu toch wel de manier, omdat je enorm veel rekenkracht tot je beschikking hebt. Ik ben van plan om de OpenGL shaderlanguage (GLSL) te gaan gebruiken. Motivatie hiervoor is dat ik hierbij voor mijn gevoel niet afhankelijk ben van bedrijven die een taal beschikbaar stellen om in te programmeren. Ik hoop op deze manier zo platform onafhankelijk mogelijk te zijn (ik werk momenteel onder linux met opengl, maar ik wil mogelijkheden open houden om dingen redelijk eenvoudig naar windows te kunnen porten).
Op dit moment weet ik er nog niet veel vanaf overigens, ik heb nog geen code geschreven voor de gpu (het enige wat ik gechecked heb is of ik opengl 2.0 code kan draaien), maar ik ben met een projectje bezig waarvoor ik dit wel wil gaan doen waarschijnlijk.

Ook ben ik wel eens bezig met imageprocessing en dergelijke en ik overweeg om, zodra ik daar weer eens aan werk, filters (gaussian, edge detection ed) op de gpu te gaan programmeren.

[H!GHGuY]

The Flying Dutchman schreef op zaterdag 15 september 2007 @ 14:18:
Ik sta op het punt om te beginnen met gpu programming. Als je leuke dingen wilt (realistisch ogende natuurkundige berekeningen bijvoorbeeld) programmeren als hobbyist, dan is de gpu toch wel de manier, omdat je enorm veel rekenkracht tot je beschikking hebt. Ik ben van plan om de OpenGL shaderlanguage (GLSL) te gaan gebruiken. Motivatie hiervoor is dat ik hierbij voor mijn gevoel niet afhankelijk ben van bedrijven die een taal beschikbaar stellen om in te programmeren. Ik hoop op deze manier zo platform onafhankelijk mogelijk te zijn (ik werk momenteel onder linux met opengl, maar ik wil mogelijkheden open houden om dingen redelijk eenvoudig naar windows te kunnen porten).
Op dit moment weet ik er nog niet veel vanaf overigens, ik heb nog geen code geschreven voor de gpu (het enige wat ik gechecked heb is of ik opengl 2.0 code kan draaien), maar ik ben met een projectje bezig waarvoor ik dit wel wil gaan doen waarschijnlijk.

Ook ben ik wel eens bezig met imageprocessing en dergelijke en ik overweeg om, zodra ik daar weer eens aan werk, filters (gaussian, edge detection ed) op de gpu te gaan programmeren.

gezien he behoorlijk platform onafhankelijk wil werken, denk ik dat je toch echt eens een blik op rapdimind moet werken. Het lijkt voor jouw toepassingen perfect geschikt.

[jvaneijk]

H!GHGuY schreef op zondag 16 september 2007 @ 08:54:
[...]


gezien he behoorlijk platform onafhankelijk wil werken, denk ik dat je toch echt eens een blik op rapdimind moet werken. Het lijkt voor jouw toepassingen perfect geschikt.

Ik ben et volledig met je eens. Rapidmind is vrij platform onafhankelijk. Ook omdat je aangeeft nog nooit echt iets gedaan te hebben op gebied van GPU programming. Is het toch wel makkelijker om een toolkit te gaan gebruiken dan gebruik te maken van een shaderlanguage, maar dat is mijn mening. Ik voorzie daar anders veel hoofdbrekers in

Als je berekeningen wilt uitvoeren moet je wel altijd in je hoofd houden dat ze moeten voldoen aan een hoge arithmetic intensity. dat is waar je altijd op moet letten. voldoet je operatie hier niet aan. dan is GPGPU niet echt de oplossing voor je probleem. Maar raytracing is supervoorbeeld hiervan of FFT

[jvaneijk]

Nog eens een kickje voor de mensen die niet weten dat hij bestaat met alle oplaaiingen over GPGPU en passwork hacking.

[The Flying Dutchman]

Ik heb mijn eerste ervaringen ondertussen opgedaan. Tenminste, ik ben op dit moment zover dat ik écht iets kan implementeren, de technische hobbels heb ik ondertussen genomen. Ik ben toch met OpenGL en GLSL aan de slag gegaan, mede omdat ik ook sinds kort de OpenGL superbible in mijn bezit heb en hier ook GLSL gebruikt wordt.

Anyway, ik ben nu zover dat ik framebuffer objecten kan maken, hier een texture aan kan koppelen waar direct in gerenderd wordt en ik heb wat simple shader programma's gemaakt met wat texture lookups om te kijken of dit allemaal werkt.

Komende week ga ik een vortex detectie algoritme implementeren (voor een vak bij mijn studie) op de gpu en als het even kan wil ik de performance gaan vergelijken met die op de cpu. Eind van de week laat ik nog wel even horen wat de verschillen zijn.

[roy-t]

The Flying Dutchman schreef op zondag 28 oktober 2007 @ 09:46:
Ik heb mijn eerste ervaringen ondertussen opgedaan. Tenminste, ik ben op dit moment zover dat ik écht iets kan implementeren, de technische hobbels heb ik ondertussen genomen. Ik ben toch met OpenGL en GLSL aan de slag gegaan, mede omdat ik ook sinds kort de OpenGL superbible in mijn bezit heb en hier ook GLSL gebruikt wordt.

Anyway, ik ben nu zover dat ik framebuffer objecten kan maken, hier een texture aan kan koppelen waar direct in gerenderd wordt en ik heb wat simple shader programma's gemaakt met wat texture lookups om te kijken of dit allemaal werkt.

Komende week ga ik een vortex detectie algoritme implementeren (voor een vak bij mijn studie) op de gpu en als het even kan wil ik de performance gaan vergelijken met die op de cpu. Eind van de week laat ik nog wel even horen wat de verschillen zijn.

GLSL is toch de tegenhanger van HLSL? Ik speel zelf wel wat met HLSL, in hoeverre dit verhoud tot de cpu weet ik niet (mijn vermoedde is sneller) maar het valt me op hoeveel je al kunt doen met iets als HLSL wat itt radmind en cuda alleen gemaakt is om shaders te programmeren.

Interresant topic dit!

[jvaneijk]

therat10430 schreef op maandag 29 oktober 2007 @ 08:11:
[...]


GLSL is toch de tegenhanger van HLSL? Ik speel zelf wel wat met HLSL, in hoeverre dit verhoud tot de cpu weet ik niet (mijn vermoedde is sneller) maar het valt me op hoeveel je al kunt doen met iets als HLSL wat itt radmind en cuda alleen gemaakt is om shaders te programmeren.

Interresant topic dit!

Volgens mij zijn Rapidmind en CUDA niet alleen maar gemaakt om shaders te programmeren maar is het juist de bedoeling om door middel van deze toolkits niet in shaders te hoeven programmeren maar meteen op een "simpele manier" met C/C++ instructies met wat extra extensies de GPU aan te sturen. En juist niet aan bepaalde onderdelen vast zitten als GLSL en HLSL. Dat je dus altijd met framebuffers moet werken en een hele OpenGL applicatie moet maken zo ong. voordat je wat kan laten berekenen.

[roy-t]

jvaneijk schreef op maandag 29 oktober 2007 @ 10:29:
[...]

Volgens mij zijn Rapidmind en CUDA niet alleen maar gemaakt om shaders te programmeren maar is het juist de bedoeling om door middel van deze toolkits niet in shaders te hoeven programmeren maar meteen op een "simpele manier" met C/C++ instructies met wat extra extensies de GPU aan te sturen. En juist niet aan bepaalde onderdelen vast zitten als GLSL en HLSL. Dat je dus altijd met framebuffers moet werken en een hele OpenGL applicatie moet maken zo ong. voordat je wat kan laten berekenen.

Eigenlijk bedoel ik wat jij bedoel: HLSL/GLSL toegespits op shaders, en daar kun je al snel veel mee uitrekenen, dat verbaasde me, dat dat ook al kon in Shader Language. Daarom stond er ook in mijn post "itt Cuda en Radmind" die echt voor C e.d. gemaakt zijn. Want daar moet het zowiezo mee kunnen want die zijn er voor gemaakt.

(hoop dat ik nu iets duidelijker ben)

[jvaneijk]

therat10430 schreef op maandag 29 oktober 2007 @ 11:43:
[...]


Eigenlijk bedoel ik wat jij bedoel: HLSL/GLSL toegespits op shaders, en daar kun je al snel veel mee uitrekenen, dat verbaasde me, dat dat ook al kon in Shader Language. Daarom stond er ook in mijn post "itt Cuda en Radmind" die echt voor C e.d. gemaakt zijn. Want daar moet het zowiezo mee kunnen want die zijn er voor gemaakt.

(hoop dat ik nu iets duidelijker ben)

Ja dit maakt een hoop duidelijk. Moet wel toegeven dat Rapidmind een stuk lastiger is dan CUDA. Dit mede doordat Rapidmind Streaming Processing Model gebruikt. CUDA maakt hier ook wel gebruik van, maar is beter geimplementeerd en daarom makkelijker te gebruiken. Ook vind ik het vervelend dat je met Rapidmind andere datatypen hebt en niet zoals gewoon een int of een float. maar een Value1f of een Value1i. Het werkt allemaal net even anders. En daar gaat best een lange tijd overheen voordat je erachter bent hoe het in elkaar zit. Wil niet zeggen dat als je gebruik maaktr van HLSL en GLSL het makkelijker is want dat is helemaal low-level programming. En je bent veelal gelimiteerd. Vooral met het gebruik van datasets (arrays) volgens mij is dat niet zo makkelijk toe te passen. Alles werkt met die RGBA enzo. Ben blij dat de toolkits er zijn!!!

[The Flying Dutchman]

Ik heb zelf ervaring met OpenGL, dan valt de stap naar GLSL wel wat mee. Zeker als je er een mooi boek bij pakt met wat voorbeelden, de GLSL shaderlanguage specificatie en je moet wel een beetje creatief nadenken over hoe je een algoritme zo handig mogelijk naar de GPU kunt overzetten.

Het opzetten van het framework is wel even lastig, maar daarna valt het me best mee eigenlijk. Binnenkort ga ik een vak volgen waar gebruik wordt gemaakt van Cg ipv GLSL. Ben wel benieuwd wat de verschillen exact zijn (verwacht dat ze klein zijn).

[jvaneijk]

Snap niet waarom ze niet meteen overstappen naar CUDA als ze Cg gaan geven. CUDA is natuurlijk mooier dan Cg als het gaat om GP. Aangezien dat ook in de toekomst het zal gaan worden zou ik het zonde vinden als ze Cg gaan geven. Let wel vind het zonde als het voor GP doeleinde is.

[Mr_gadget]

offtopic:
Zijn er al "echte" applicaties voor de videokaart? (behalve games natuurlijk). Heb hier namelijk een 9800 Pro videokaart liggen die geen goed beeld geeft, deze zou misschien in een 500mhz pc'tje kunnen helpen

[jvaneijk]

Mr_gadget schreef op maandag 29 oktober 2007 @ 13:15:

offtopic:
Zijn er al "echte" applicaties voor de videokaart? (behalve games natuurlijk). Heb hier namelijk een 9800 Pro videokaart liggen die geen goed beeld geeft, deze zou misschien in een 500mhz pc'tje kunnen helpen

Er zijn wel degelijk applicaties gemaakt die draaien op de GPU denk bijvoorbeeld aan medische applicaties. FFT in MRI software. Hier is Siemens Medical Solutions al druk mee bezig. En zo zijn er tal van andere applicaties. Ook als je zelf iets met pattern recognition (Neurale Netwerken) wil gaan doen kan dat uitstekend op de GPU.

[mOrPhie]

jvaneijk schreef op maandag 29 oktober 2007 @ 13:04:
Snap niet waarom ze niet meteen overstappen naar CUDA als ze Cg gaan geven.

Ik denk omdat Cg van origine een graphics-taal is. CUDA gebruikt in essentie natuurlijk dezelfde registers, maar is ontworpen met supercomputing in het achterhoofd, niet graphics.

[jvaneijk]

mOrPhie schreef op maandag 29 oktober 2007 @ 13:46:
[...]


Ik denk omdat Cg van origine een graphics-taal is. CUDA gebruikt in essentie natuurlijk dezelfde registers, maar is ontworpen met supercomputing in het achterhoofd, niet graphics.

Precies wat ik zeggen wou

[.oisyn]

Mr_gadget schreef op maandag 29 oktober 2007 @ 13:15:

offtopic:
Zijn er al "echte" applicaties voor de videokaart? (behalve games natuurlijk). Heb hier namelijk een 9800 Pro videokaart liggen die geen goed beeld geeft, deze zou misschien in een 500mhz pc'tje kunnen helpen

Sowieso is jouw 9800 een SM 2.0 kaart, dus de mogelijkheden zijn erg gelimiteerd. GPGPU wordt pas echt zinnig met SM 3.0 (nog beter is natuurlijk 4.0, maar soit )

[jvaneijk]

Tesla Server met SM4.0 en 6GB GDDR3 is wel goed. Met CUDA / Rapidmind

[jvaneijk]

Nogmaals een trapje. Aangezien er steeds meer berichten komen over GPGPU / Stream processing

[RobIII]

jvaneijk schreef op vrijdag 09 november 2007 @ 14:39:
Nogmaals een trapje. Aangezien er steeds meer berichten komen over GPGPU / Stream processing

Het komt vanzelf wel weer omhoog als het interessant is voor iemand; je hoeft dit topic niet te blijven schoppen; dit is al de 3e keer

jvaneijk in "[ALG] Ervaringen GPGPU"
jvaneijk in "[ALG] Ervaringen GPGPU"
jvaneijk in "[ALG] Ervaringen GPGPU"

[ Voor 28% gewijzigd door RobIII op 09-11-2007 15:01 ]

[The Flying Dutchman]

Ik dacht, laat ik dit topic weer eens opzoeken (had tenslotte ook min of meer beloofd nog wat te laten horen).

jvaneijk schreef op maandag 29 oktober 2007 @ 13:04:
Snap niet waarom ze niet meteen overstappen naar CUDA als ze Cg gaan geven. CUDA is natuurlijk mooier dan Cg als het gaat om GP. Aangezien dat ook in de toekomst het zal gaan worden zou ik het zonde vinden als ze Cg gaan geven. Let wel vind het zonde als het voor GP doeleinde is.

Het vak dat ik volg gaat niet over GPGPU, maar het is meer een computer graphics vak, vandaar dat Cg gebruikt wordt. Er zijn wel linkjes naar GPGPU. Zo heb ik afgelopen week een presentatie gegeven over een artikel genaamd 'a million particle system' (Lutz Latta, 2004), waarin posities, snelheden, acceleratie, collisions, etc. op de GPU worden berekend. Een erg interessant artikel.

Over het vortex detectie algoritme waar ik mee bezig was:
Door tijdgebrek heb ik het niet uitgebreid kunnen optimaliseren, laat staan testen. Het werkte, ik heb er enkele tests mee uitgevoerd, maar de performance op mijn 7600GS was ongeveer gelijk aan de performance op een ati 9800pro, gebruikt door de auteurs vh oorspronkelijke artikel. Nu had ik het algoritme in een paar dagen gemaakt, zonder enige optimalisaties (en net beginnende met GPGPU dingen) dus er was nog wel wat progressie mogelijk, maar ik had gewoon niet meer tijd om het uit te werken. Een vergelijking met de CPU is er dan ook niet meer van gekomen.

De laatste tijd ben ik wel steeds meer bezig met GPU dingen, maar die zijn vaak zwaar gerelateerd aan computer graphics (behalve dat computer graphics vak dat ik volg, doe ik met een paar studiegenoten mee aan de four elements wedstrijd van gamedev.net), maar het blijft me wel verbazen wat jet met zo'n gpu allemaal kunt!

[writser]

The Flying Dutchman schreef op zondag 02 december 2007 @ 11:44:
Het vak dat ik volg gaat niet over GPGPU, maar het is meer een computer graphics vak, vandaar dat Cg gebruikt wordt. Er zijn wel linkjes naar GPGPU. Zo heb ik afgelopen week een presentatie gegeven over een artikel genaamd 'a million particle system' (Lutz Latta, 2004), waarin posities, snelheden, acceleratie, collisions, etc. op de GPU worden berekend. Een erg interessant artikel.

offtopic:
RuG?

[The Flying Dutchman]

writser schreef op zondag 02 december 2007 @ 12:02:
[...]

offtopic:
RuG?

offtopic:
jep
edit: ik doe de master Artificial Intelligence
voor de geinteresseerden: de vakken waar ik het over had zijn van de master informatica (mag ik ook opnemen in keuze ruimte), het gaat om de vakken 'scientific visualization' en 'advanced computer graphics'

[ Voor 42% gewijzigd door The Flying Dutchman op 02-12-2007 12:51 ]

[Verwijderd]

offtopic:
Ik zit er hard over te denken om die master ook te gaan volgen.
Nu heb ik wel een aardig overzicht van de vakken die er te volgen zijn (ocasys bekeken).
Maar kun je me misschien wat vertellen over je 'user experience' op school en wat huiswerk gerelateerde zaken, middels mail oid, dit is wel topickaping

[jvaneijk]

Ik ben zelf nu bezig met afstuderen.. in het AMC, en in September ga ik beginnen aan de Master Neuroscience aan de VU. Ik heb ook enkele vakken gevolgt op het gebied van Artificial Intelligence en dan met name Neural networks en Fuzzy logic enz enz. En nu wil ik mijn neurale netwerk dat ik ooit eens heb gebouwt om gaan zetten zodat het op de GPU draait Om te zien of die Back prop. een beetje sneller is met trainen dan op je C2D. Als mensen al enige ervaring hiermee hebben hoor ik het graag.

[jvaneijk]

Nog steeds niemand die met GPGPU een back prop. NN heeft gemaakt?

[jvaneijk]

Eens even een schopje geven.

[ATS]

Ik wil voor wetenschappelijk werk ook gebruik gaan maken van de parallelle mogelijkheden die moderne systemen en vooral GPU's bieden. Ik heb daarover op het moment twee vragen:

1. Uit wat ik tot nu toe lees, lijkt het alsof de meeste toolkits uit gaan van een 1 tot 3 dimensionale array van input en output variabelen. Hetgeen ik wil gaan doen komt grotendeels neer op het vergelijken van arrays: ik heb een lange array (denk aan 10K tot 1M elementen) van arrays van integers (1 tot 100 elementen ongeveer). Nu wil ik voor elke combinatie van element uit de grote array tellen hoeveel van de integers in hun respectievelijke data array overeen komen. Op zich is dat probleem natuurlijk uitstekend paralleliseerbaar, maar krijg ik mijn dataset wel in een formaat dat dit ook lukt en snel wordt met de toolkits die er zijn (Rapidmind of Cuda ofzo).
2. Ik zie verschillende mensen Rapidmind noemen als oplossing om naar te kijken. Het ziet er interessant uit, vooral omdat het een crossplatform oplossing biedt (dat wil zeggen: werkt op gewone multi-cores, maar ook op ATI en nVidia videokaarten en zelfs op Cell). Leuk, maar ik zie nergens op die site een link hoe je aan dit pakket zou moeten komen? Is het beschikbaar voor gebruik in een open source applicatie bijvoorbeeld?

[Zoijar]

Met CUDA zit je niet vast aan 1-3 dim arrays; je kan gewoon device geheugen alloceren net als in C met cudaMalloc.

http://www.pubmedcentral....render.fcgi?artid=2323659 ?

[ Voor 24% gewijzigd door Zoijar op 22-10-2008 13:53 ]