Nvidia ondersteunt Kepler-gpgpu met Cuda 5

Nvidia heeft versie 5 van zijn Cuda-platform uitgebracht. De nieuwe Cuda moet de gpgpu-mogelijkheden ondersteunen van gpu's op basis van de Kepler-architectuur. Een van de nieuwe features in Cuda 5 is GPU Direct via pci-express en ethernet.

Een van de problemen van gpgpu-toepassingen is dat een videokaart toegang heeft tot relatief weinig eigen werkgeheugen. Hierdoor kan een flessenhals ontstaan bij het ophalen van meer data die naar het videogeheugen gekopieerd moet worden. Nvidia's GPU Direct-technologie, die in Cuda 5 is te gebruiken, zou in combinatie met een Kepler-gpu echter videogeheugen van andere gpu's kunnen aanroepen. Dit kan via de pci-express-bus of de netwerkkaart om zo andere nodes in een cluster aan te spreken. Hierdoor zouden de latency-tijden korter worden, zo stelt de gpu-fabrikant.

Nvidia heeft in Cuda 5 ook de feature dynamic parallelism opgenomen. Hiermee kan een Cuda-programmeur binnen een gpu multi-threaded code starten waardoor er minder vertragende communicatie nodig is met de cpu. Ook kan binnen de gpu toegang worden verkregen tot bepaalde libraries, waardoor opnieuw communicatie met de cpu overbodig wordt.

Voor Cuda 5 heeft Nvidia verder Nsight Eclipse uitgebracht. Binnen de Eclipse-ontwikkelomgeving krijgt Cuda-code voortaan syntax highlighting, maar de ide biedt ook een debugger en code profiler. Nsight Eclipse is beschikbaar voor Linux en OS X.

Reacties (42)

Yup, Cuda is een doodlopende weg. Developers zullen sneller kiezen voor opem platformen, die op meerdere typen gpu's werken:

http://www.streamcomputin...l-vs-cuda-misconceptions/

Ik zie toch meer inovatie komen uit de goed gedocumenteerde Cuda omgeving, dan door een open paralelle computing omgeving. Rechten om bepaalde technieken te gebruiken zijn niet het probleem bij Cuda, alleen Nvidia zelf kent immers alle ins en outs van het Kepler ontwerp, maar ik weet niet hoeveel ze vrij gegeven hebben voor ontwikkelaars om te gerbuieken in API's.

Waarom zou open GPU met ontwikkelomgeving meer GFLOPS op kunnen leveren
? En waarom verschillende GPU samen willen laten werken, uit economische redenen? Ik zie daar het nut niet van in.

[Reactie gewijzigd door CheapElectronic op 16 oktober 2012 01:54]

Beide modellen hebben zo hun voor- en nadelen.

Open betekent dat je met heel wat partijen rond de tafel moet zitten om te beslissen wat in de standaard komt: dat neemt heel wat tijd en zorgt altijd voor compromissen (het zal nooit het onderste uit de kan halen van de hardware van iedere fabrikant).

Gesloten betekent dan weer vendor lock-in wat niet wenselijk is.

Welke van beide modellen gekozen wordt hangt af van de afweging die je maakt tussen ieders voor- en nadelen.

Is vergelijkbaar met DirectX vs OpenGL. Daar zie je ook dat DirectX voor games beter doorbreekt: games zijn meer tijdgebonden (moet snel gebruik kunnen maken van nieuwste technieken, voor een volgende game kan makkelijker naar een concurrerende techniek overgestapt worden). OpenGL is dan weer populairder bij app-bouwers omdat apps over het algemeen langer blijven bestaan en vendor lock-in dan zwaarder doorweegt...

Daar komt nog bij dat als je echt het onderste uit de kan wil halen, je sowieso specifiek voor een bepaalde architectuur gaat programmeren. Bv door gebruik te maken van het feit dat een warp exact 32 threads breed is, en je dus een warp synchronisatie kan vermijden. Of bv eigenaardigheden van het memory systeem (bank conflicts in shared memory; coalescing).

Dan maakt de API niks meer uit, je hebt je ziel reeds verkocht aan een specifieke GPU

de volgende stap zou resource pooling kunnen zijn waarbij het over de kaarten verspreide geheugen als 1 enkele adresspace benaderbaar is middels caching en virtualisatie en ook de vertex shaders tot 1 virtuele kaart worden samengesmolten.

Zodat je geen controle meer hebt over op welke gpu/node je stukje data opgeslagen staat, en de middleware pas halverwege je run heeft kunnen bepalen wat de efficiëntste opslag lokatie is? Caching is leuk zolang je meer leest dan schrijft. Ik denk dat een applicatie/algoritme schrijver liever een gescheiden address space heeft, met wel de mogelijkheid om andere nodes direct te benaderen, dan een abstractie waardoor je data spontaan niet meerlokaal kan zijn.

dynamic parallelism klinkt heel cool.

Moet voor stage OpenCL en vision dingen doen en deze functie mocht het zijn wat ik denk dat het is(Kernels starten vanuit andere kernels). Zou het programeren van sommige dingen stukken sneller maken.

Dat is precies wat het is, weliswaar met enkele beperkingen mbt maximaal aantal kernels in flight en ook de communicatie en synchronisatie onderling. Dus je kan niet alles gaan doen, maar wel op natuurlijke en elegante wijze recursieve algoritmes als een quicksort gaan implementeren. Maar nogmaals enkel vanaf GK110 dus niet de 690.

EIndelijk! Laten we hopen dat softwareproducten die CUDA gebruiken snel up-to-speed (letterlijk) zijn met deze versie. Ik zit al maanden te wachten op een performante Kepler-versie van Octane Render. Begin van de zomer speciaal nog een GTX 570 gekocht aangezien deze chip 40% sneller is dan een GTX 680 in Octane Render. . . hopelijk kan ik binnenkort upgraden .

@ Ché Ming:
Niet alleen omdat de shader clocks sneller zijn. De CUDA-cores van Fermi zijn ook iets geavanceerder dan die van Kepler. (Voor zover ik me kan herinneren .) Dat maakt dat Fermi tot nog toe sneller was in bepaalde applicaties. Ondanks de hoop extra CUDA-cores van Kepler. Zie je ook duidelijk terug in alle benckmarks gerelateerd aan GPU-processing met Kepler.

[Reactie gewijzigd door 6129(15) op 15 oktober 2012 20:34]

Ik zou daar niet te veel op rekenen. Kepler heeft geen hardware scheduler en is juist langzamer als je hogere precisie wil gebruiken (zoals in een renderer). Daar gaat een nieuwe versie van Cuda vast niet veel aan veranderen...

Hoezo kepler heeft geen scheduler, het nieuwe dynamic parallellisme is precies de mogelijkheid om meerdere verschillende kernels tegelijk af te vuren, en dan eventueel van binnen een draaiende warp nog bijkomende kernels te lanceren. Weliswaar enkel vanaf GK110, maar toch

de instructie-prefetcher en optimizer van kepler zijn stukken simpler dan van Fermi.
Alles om meer game-performance uit minder stroom te halen. Sinds launch was al duidelijk dat compute performance ingestort is (bewuste keuze) onder Kepler ten opzichte van Fermi.

Octane gaat op single precision en niet op double precision. En ik geloof dat Keller juist heel sterk was in single precision calculations.

Maar moet Octane dan niet een update krijgen om ook CUDA 5.0 te ondersteunen of zo?

ik wil ook een keer proberen te renderen met Octane, maar moet ik apart CUDA drivers installeren, of zitten deze in de geforce drivers?

Zitten in de GeForce drivers (voor elk platform)

[off-topic]
Bedoel je nou dat een GTX 570 eigenlijk 'sneller is' onder CUDA 4 omdat de shader clock speed anderhalf keer zo hoog is als die van een GTX 680?
Ik nam aan dat de GTX 680 ter (ruime) compensatie daarom dan ook bijna 3 keer zoveel shaders heeft. Maar als ik je goed begrijp maakt dat niets uit voor 'oude' CUDA 4 apps?
[/off-topic]

Zo offtopic is dat niet lijkt me. Ik kan me applicaties voorstellen waarin meer shader cores gewoon niks oplost. Zodra je met beeldlijnen (zoals in een renderer) gaat werken dan hebben meer cores niet altijd evenveel nut, omdat velen ervan uit hun neus zullen staan eten zodra je een mismatch hebt tussen het aantal beeldlijnen en het aantal cores. Dan liever een hogere clock. Een concreet voorbeeld van het nut van CUDA 5 is dus nu al gevonden in het topic

Precies, een probleem dat in Kepler nog versterkt is doordat ze nu een dual issue scheduler gebruiken. Er zijn meer cores dan er actieve threads in een warp zijn en de bedoeling is dat twee instructies tegelijk verwerkt worden in de odd/even stijl van bv een PS2. Dat vereist enig werk van de compiler, dus het is mogelijk dat oude Cuda code hercompileren met Cuda 5 alsnog een snellere kernel oplevert dan Cuda 4 op een gtx580.

In de nieuwste build is een gtx 690 even snel als een gtx 590 en een Gtx680 is 10-20% langzamer dan een gtx580. Voordeel van de 690 en 680 is dat ze meer geheugen hebben (dus meer textures, geometrie en resolutie aankunnen).
Verder hebben ze bij otoy nog wat ideeën om de performance dramatisch te verbeteren maar dan moeten ze heel wat code herschijven.
Dit stellen ze daarom nog even uit. Ze vinden andere features belangrijker op het moment dan nog meer performance (bijvoorbeeld displacment of betere integratie in Maya 3dmax of andere 3D pakketten).

Edit: @ hier onder, helaas een 2dehands 5 serie geforce is op het moment het beste (geld per performance). Ook al is in de nieuwe build de gtx580 langzamer dan in de vorige builds. Ook begreep ik dan de nieuwe drivers van de 5 serie voor minder performance zorgde.
Ik blijf dus bij de oude octane build met oude drivers, dat zorgt voor de snelste renders.

[Reactie gewijzigd door nr12 op 15 oktober 2012 21:10]

Dus als je qua performance er op vooruit wilt gaan voor de laagste prijs, is het zelfs met deze 5.0 toolkit niet zo logisch om voor de 680/90 te gaan?

Niet alleen de shaders maar ook de scheduler en nog wat andere zaken. Little Kepler is geen GPGPU chip. Big Kepler die nog niet uitgekomen is (AKA GK110) was wel op GPGPU gericht. Misschien gaan die nog wel zien en misschien ook niet meer in die vorm maar misschien wel in de vorm van een refresh voor de 7xx generatie.

Dat Cuda nog ontwikkelt wordt.
Ik las laatst iets dat Adobe pakketten het al droppen en overgaan op open CL of GL.
Kan ook verkeerd gelezen zijn natuurlijk.

Ja want als ze in China de snelste supercomputer ter wereld aaneen lijmen met nvidia kaartjes, kijken ze wel eerst even wat adobe doet, natuurlijk . Naast features is ook de performance van doorgaans beter dan OpenCL.

Zorg dan wel dat je je feiten juist hebt.
- Snelste computer staat niet in China. http://www.top500.org/lists/2012/06 - Ze waren de snelste in 2010.
- In 2010 was NVIDIA de enige fabrikant die zowel een relatief goedkope en goed programmeerbare vector-processor had. Maar dat is alweer twee jaar geleden en de tijden zijn veranderd.
- Als je iets als "float8 A = 2*B" in een CUDA-, Fortran of OpenCL-programma intikt, dan hangt het af van de hardware en niet van de software, hoe snel dat loopt. Er zijn vele algoritmes die sneller lopen op een Radeon of CPU (beide programmeerbaar met OpenCL, trouwens).
- Het gaat tegenwoordig minder om de GFLOPS per €uro, maar om de GFLOPS per Watt.

Bedankt voor de correctie, ik had niet in de gaten dat het alweer 2 jaar geleden was.

Dat het van de software afhangt is juist, maar bij software die voor meerdere APIs beschikbaar is lijkt CUDA het toch dikwijls te halen (zie bv. het recent vrijgegeven tool voor DX11 BC6 compressie) -- maar dat kan natuurlijk aan de programmeurs liggen.

GFlops per watt heeft NVidia heel goed begrepen en lijkt het centrale thema te zijn voor Kepler, dus ook daarop zou ik ze niet afschrijven

Kan je wel lekker sarcastisch lopen doen, maar dit was gewoon een opmerking zodat ik antwoordt erop kreeg.
Ik ben hier totaal niet in thuis, dus het lijkt me heel normaal dat ik er door een reactie te palatsen meer over hoor.

Ach, gewoon een flauwe mop alvorens ter zake te melden dat de performantie van Cuda nog steeds voor loopt op de rest. Wou niet beledigen, excuses

Was ook niet beledigend opgenomen. Maar vond t een beetje een vreemde reactie op een serieus comment.

Adobe dropt ook zijn eigen flash, blijkbaar is het besmettelijk. CUDA mag dan NVidia specifiek zijn, de tools en features zijn wel vele malen beter dan de OpenCL/GL competitie (imho)

Weet niet OpenCL met AMD zijn tools is goed te doen maar dan heb ik ook niet ervaring met cuda of Nsight. Misschien dat Ms C++AMP iets wordt is ook een open Standard.

C++ AMP is net zo open standaard als bijna alle andere "open" standaarden van Microsoft: het werkt alleen goed met hun eigen software, en is niet of nauwelijks te porteren. De specificatie beschrijft diverse afhankelijkheden van Windows systeem-API's en DirectX. Dat betekent dat het niet of met heel veel moeite te implementeren is op Android, iOS, Linux of OSX. Ergo: geen open standaard, maar goede marketing.
Goed nieuws is dat er bovenop OpenCL diverse high-level programmeertalen gebouwd worden.

De mogelijkheid dat de GPU direct via ethernet fdata ophaalt ben ik niet kapot van. Het is gewoon wachten totdat er iemand op deze manier een virus verspreid.

[Reactie gewijzigd door jeroenathome op 15 oktober 2012 21:07]

ethernet is niet altijd internet he

kan ook gewoon een verbinding zijn op een intern netwerk

Maakt niet uit, bedoel een VPN lost het probleem alweer op als het niet "direct" via het internet kan. (zo zijn nog wel meer methodes)

Zo te zien gaat GPUDirect vooral om het kopiëren van buffers, niet om het kopiëren van shaders. Hoe je het geheel wil synchroniseren is een ander verhaal, maar als je niet toestaat om shaders over te zetten, moet het geen kwaad kunnen.

Het gaat hier dus ook om inter connects in clusters ... niet voor een huis tuin en keuken netwerkje. Met een gbit netwerkje gaat dit niet werken namelijk

Flessennek, moest het echt even 2x lezen.

-hals

bottleneck was beter geweest ja,

Zo heet dat idd in het Nederlands.

fles·sen·hals (de; m; meervoud: flessenhalzen)
1
hals van een fles
2
knelpunt, bottleneck