Nvidia maakt C-compiler voor G80-core

Nvidia heeft een C-compiler uitgebracht waarmee de nieuwe G80-core voor niet-grafische toepassingen kan worden ingezet. De zogeheten Cuda-technologie, die in de nieuwe chip zijn debuut maakt, laat programmeurs de unified shaders van de chip gebruiken als een soort losse processortjes. Daardoor kan een G80 concurreren met de physics-kaarten die games moeten versnellen, maar ook het rekenwerk aan bijvoorbeeld elektrotechnische of geologische modellen zou veel goedkoper uitgevoerd kunnen worden. Naast de G80 zal ook de zakelijke Quadro-lijn Cuda-ondersteuning krijgen, en het laat zich raden dat de lijst in de toekomst alleen maar langer wordt. Het platform wordt voor zowel Windows XP als Linux 'gelijkwaardig' ondersteund. ATi werkt met PeakStream aan een vergelijkbaar concept, wat onlangs de eerste resultaten opleverde, maar volgens nVidia is dat knip- en plakwerk met bestaand materiaal: het geheel nieuwe Cuda is vanaf de grond opgetrokken en daarom veel sneller dan de concurrentie.

Een pc met bijvoorbeeld een GeForce 8800 GTX krijgt er dankzij de Cuda-architectuur 'zomaar' 128 op 1,1GHz geklokte miniprocessortjes bij. Om het parallellisme van de gpu te benutten moeten instructies en data echter op een andere manier geordend worden dan bij klassieke Von Neumann-programma's, waarbij maar één instructie tegelijk in de gaten gehouden hoeft te worden. Bovendien heeft de 'stream processor' van nVidia geen normale processorregisters, maar krijgen de threads dynamisch stukjes cachegeheugen toebedeeld, wat ook nogal wat organisatietalent van de developers vraagt. Dat gaat helemaal op als meerdere shaders aan dezelfde gegevens moeten werken, maar het hergebruik van gecachete gegevens levert volgens nVidia wel een belangrijk snelheidsvoordeel op. Om toch niet teveel hardwarekennis van de programmeur te eisen, is nVidia's C-compiler van een soort cpu-gpu-driver voorzien, die in samenwerking met OpenGL- en DirectX-drivers de gpu van werk voorziet. De oorspronkelijk videofunctie van de G80 komt zo wel wat in het geding, en de verwachting is dan ook dat de Cuda-chips binnen afzienbare tijd voor met name zakelijke toepassingen ook zonder monitoraansturing te koop zullen zijn.

Reacties (47)

[Anoniem: 48923]

Wordt het niet eens tijd dat een bedrijf een losse kaart gaat maken waar op je een x aantal cpu's kan klikken voor dit soort doeleindes?
Dat hoeft dan ook niet zo duur te zijn en als je je games of tools wat sneller wilt hebben (ze moeten het dan wel ondersteunen maar dat is logisch) dan koop je een cpu erbij.

@dmantione :Lijkt inderdaad wel leuk ja... helaas maar voor een 3 tal tools. Maar iemand moet beginnen natuurlijk :-) Het game vlak lijkt me een goed begin

@Ackermans1973 : zeker niet...als het een GPU is dan is het bedoeld voor grafische dingen.. Maar misschien ook weer geen CPU want dat is de centrale eenheid. ff denken.... SPU (Secondary processing unit) lijkt me een goede

@thekip : als ik kijk naar een raid controller met geheugen erop dan werkt dat ook prima. Daar zit bv een risc cpu op. Je stopt er 256MB geheugen in (kost toch geen ruk meer) en klaar. Een extra kaart met verbindingen is het niet echt. Nu heb je een video kaart (ook extra eigenlijk) waar je de software op draait. Dan heb je een extra kaart waar bv 4 spu's op draaien. Ik denk niet dat het een probleem is om zoiets te ontwikkelen, alleen het supporten zal moeilijk zijn omdat bedrijven die moeten inbouwen in hun software.

[dmantione]

http://www.clearspeed.com/products/csx600/

[Ackermans1973]

Bedoel je niet GPU i.p.v. CPU...

[Anoniem: 47200]

zoiezo is dit hele systeem zo snel doordat alles op het bord vastgesoldeerd zit, dat scheelt weer verbindingen via een (toch nog steeds) minder betrouwbaar socket. daarnaast is het lastig om een dergelijke kaart te maken omdat je er ook geheugen etc bij moet steken en die verhouding is erg belangrijk.

@hierboven
ja en je zit aan de breedte van de pus van je insteekkaart en bij heel veel communicatie met het systeem kan dat ook weleens de bottleneck worden (hoe krijg je bijvoorbeeld alle benodigde gegevens in het geheugen op je kaart.....)

[Anoniem: 47102]

Dat is er al, de socket heet PCI-E 16x en de CPU heet G80 kaart.

m.a.w. door losse chips te maken verschuif je alleen je uitbereidingspunt. Als je tegen de limiet van het aantal 16x sloten loopt (3 max zover ik weet momenteel) waarom zou je dat probleem dan ineens niet meer hebben als je met chips in sockets i.p.v. kaarten in slots werkt?

[d_star]

Is dit misschien een klein beetje een voorbereiding op het gerucht dat Nvidia in de CPU markt wil stappen?

Bron: http://news.com.com/2061-11516_3-6128186.html

Ik kan me namelijk voorstellen dat het aanmoedigen van gebruikers voor het gebruiken van gpu-cores voor andere doeleinden dan grafische toepassingen, best een mooie test kan zijn van Nvidia om de horizon te verbreden.

[leuk_he]

Dat nieuwsbericht ging over een x86 CPU. deze GPU als cpu ( of een 128 core CPU...) is echt NIET x86 compatible. En ook de C code die je erop draait zul je echt moeten richten op het verwerken van dingen die gespecialiseerd zijn voor een GPU. Anders houd je geen performance meer over.

[Astennu]

Neeh maar Nvidia heeft de G80 core wel ontworpen met technieken die ook veel bij cpu's worden gebruikt. Zo complex is deze G80. Dit geeft wel aan dat Nvidia die kant op gaat.

Dus misschien zullen in de toekomst wel een X86 cpu gaan maken wie weet....

[newinca]

Welke technieken mogen dat dan wel zijn?
G80: massief parallel theads, SIMD, in-order, scalar, latency hiding, enz enz.
x86: single threaded, SISD, out-of-order, super-scalar, register renaming, enz enz.
De voornaamste overeenkomst is dat ze instructie uitvoeren. Maar het blijven heel verschillende beestjes en de core is execution unit van een x86 is een orde grootte complexer dan die van een GPU.
Afhankelijk van de bron claimt Nvidia 600 tot 1000 manjaren werk voor de G80. Daar lachen Intel en AMD mee.

[Thedr]

Whoehoei... VHDL krijgt nieuwe betekenis: Video Hardware Description Language

Ik vind dit een zeer interessante ontwikkeling als digitaal systeemontwerper zijnde, maar vraag mezelf af of een FPGA op een HyperTransport socket misschien niet sneller en waarschijnlijk sowieso flexibeler is. Van die shader architectuur heb ik niet zoveel kaas gegeten, maar me dunkt dat daar lang niet alle bewerkingen op uitgevoerd kunnen worden. Een FPGA blijft dan nog steeds een stuk flexibeler lijkt me?

-edit-

@newinca:

Ik houd m'n eerste reactie maar even voor me, maar toch es eea opgezocht over wat je zegt (of eigenlijk jammer genoeg, niet zegt). Alles moet worden geleerd en:
I was just wondering and being interested... (net afgestudeerd, dus kom nog maar net kijken in 't DSO vak...)

Het is een hele berg rekenkracht die in de G80 zit, en al helemaal als je idd in ogenschouw neemt dat de hardware hiervoor voor €600 in de winkel te koop is. Het is ook zeker niet tot even 3 tellen voor je een andere/gelijkwaardige oplossing hebt.
Echter blijft 't niet zo dat dit alleen geschikt is voor een specifiek soort bewerking, waar een FPGA redelijk eenvoudig opnieuw gemapped kan worden voor andere soorten bewerkingen?
Natuurlijk is het (met de huidige stand der techniek) niet mogelijk om die 128 SIMD proc's op 1,35 GHz in een FPGA te proppen. Een FPGA op een HT socket bied ook een aardig potentieel, echter zie ik in dat dit voor deze toepassing niet geschikt is (te weinig bandbreedte, enz... i know).

[newinca]

Juist ja. Al wat je moet doen is even vlug een een FPGA vinden waarop je 128 SIMD processoren kan implementeren die elk een volwaardige IEEE754 MADD bevatten en aan 1.35 GHz draaien. Enkel nog wat drammetjes toevoegen (12 bijvoorbeeld). Een thread processor om alles te schedulen.
Vervolgens ook nog even een C-compiler schrijven die dat allemaal kan aansturen.
En klaar is Kees. Dat is toch allemaal veel efficienter dan de winkel instappen en 600 Euro neerleggen.

Denk toch eens na, man...

Indrukwekkend wel dat je VHDL kent. Heb je daar lang op gestudeerd?

[newinca]

De grootste FPGAs zijn ongeveer even groot als een G80 en bevatten ongeveer evenveel transistoren. Maar het effectief aantal equivalente ASIC gates per mm2 is ongeveer 10 keer lager.
De maximale bereikbare kloksnelheid voor redelijk complexe logica is ook een stuk lager. Laat ons zeggen, maximaal 400 MHz (en dat is een heel liefdadige toegeving voor de FPGA. Misschien wel wat hoger voor de interface logica.) Dus 3 a 4 keer trager.

De kostprijs van zo'n top-of-the-bill FPGA zal ergens rond de $10000 liggen. (!!!)

Maar het moeilijkste moet dus nog komen: voor al dat geld krijg je nog steeds enkel een berg ongeprogrammeerde logica. Als je hierop een gespecialiseerd algoritme wil programmeren (dat per cycle waarschijnlijk wel een stuk efficienter *kan* zijn dan een GPU), dan heb je meerdere manjaren nodig om die FPGA vol te krijgen en te verifieren, tenzij het een perfect paralleliseerbaar algoritme is waarvan je er honderden op 1 FPGA kan zetten.

Ingenieurs- en programmeurstijd is duur. In die mate dat zelfs Cg of eender welke HSLS te veel moeite en tijd vraagt om een GPU te programeren: als je wilt dat je stuk hardware echt gebruikt wordt door een grote massa, *moet* je bijna een C-compiler hebben.

Met een FPGA en VHDL ben je zover verwijderd van dit ideaal dat het in de praktijk nooit gebruikt wordt..

(Mijn excuses voor de wat overdreven reactie. Proficiat met je diploma. Ik wens je een interessante job toe waarin je veel kan bijleren: dat laatste is voor mij persoonlijk nog altijd een van de hoofdargumenten als ik van werk verander.)

[Anoniem: 194702]

Fijn op dit soort ontwikkelingen zit ik te wachten.
Ziet niet te wachten op telkens losse insteekkaartjes.

Prettig toch als je performance toeneemt door 1 kaart?
Physics, graphics etc op 1 kaart.

Simulaties in 3dsmax die versnelt worden.
En mooiere physics in games.
Alles wordt er alleen maar beter op.
Voor game-ontwikkelaars ook heel erg interessant lijkt mij...

Laat maar komen hoor!

[MacD]

Laat 3dsmax maar eens eerste gebruik maken van de GPU bij het renderen...jaren geleden bij SIGGRAPH een demo van geweest (gigantische snelheidswinst), en nu nog steeds niet in max te doen

[simen]

dat is allang te doen, nvidia heeft daar een 3dsmax renderer voor gemaakt en er bestaan er al een hoop meer.

check je info voor je post

zoek maar eens naar Gelato

[Anoniem: 173922]

Dan mag je mij eens laten zien hoe ik b.v. glow bij een lightning krijg in Maya op Hardware render.

[Anoniem: 77640]

Ook interessant is ray-tracing. 128 pixels in parallel. Het mag dan nog vele duizenden klokcycli duren, dan is het nog real-time.

[leuk_he]

Bij raytracing heb je te maken met een boel lookups. if vraag me af of multicore traditionele processors dat juist niet beter kunnen.

Overigens kun je met google wel wat onderzoek hiernaar vinden:

raytraces on gpu:
http://www.clockworkcoders.com/oglsl/rt/

[Anoniem: 111970]

Vergeet echter niet dat je met raytracen ook een hoop met floating point en bepaalde operaties daarop te maken hebt - dot product bijvoorbeeld. Die heeft Intel nog maar net op de planning staan als enkele processor functie maar is in GPUs al jaren aanwezig. Ik ken iig -een- ontwikkelaar van een raytracer die kwijlde bij het bericht van de G80 met IEEEnogwat certificering (wat zoveel inhoud dat een floating point operatie op die kaart hetzelfde resultaat geeft als op de CPU - en dat was nog een klein, maar belangrijk, struikelblok)

[Anoniem: 112442]

Dit moet je in gcc kunnen gebruiken. Dan kan je de video kaart als co-processor laten werken voor vector berekeningen.

[Anoniem: 75364]

Dat gaat zo maar niet.

Dan moet GCC eerst een flink stuk van je applicatie source code zien te isoleren die 100% op de GPU kan draaien, vervolgens dit stuk code laten uploaden naar de GPU, de benodigde input data uploaden, de code draaien, en de uitkomsten weer downloaden.

Dat wordt een flinke verbouwing als je een reguliere compiler zoals GCC dat wil kunnen laten doen. En slechts enkele programma's hebben er baat bij.

Ik denk dat de overhead van de up/download stap te groot is om GPU en CPU op instructie-level te kunnen mengen.

[Anoniem: 42832]

Dat wordt dus echt erg boeiend als er iemand een h264 codec omzet naar unified shader code.

Wat in theorie wel moet kunnen omdat het in principe redelijk gelijk lopende DSP achtige dataprocessing is.

H264 encoden op 128 parallel lopende processen, dat moet echt met een bloedgang kunnen gebeuren

(maar dan echt he, niet net als ze nu beweren een encoder te hebben die op de GPU draait, maar stiekum toch op de CPU draait)

[Anoniem: 116213]

DivX is er vaak als de kippen bij om dit soort nieuwe technieken te ondersteunen. En XviD volgt dan ook snel, of kan dit als een kans zien om voorsprong te nemen.

En video-editing/transcoding leent zich inderdaad perfect voor multi-core, waarbij de 'cache' functie van de registers ook nog extra kan helpen bij B-frame calculaties.

[BRAINLESS01]

Waarom werkt dit nou niet op oudere nvidia kaarten? Er is toch niks veranderd aan de architectuur van de kaart, er is alleen een andere manier bijgekomen om hem aan te sturen, of mis ik iets?

[Anoniem: 62011]

De zogeheten Cuda-technologie, die in de nieuwe chip zijn debuut maakt, laat programmeurs de unified shaders van de chip gebruiken als een soort losse processortjes.

[martijnvanegdom]

De architecteur niet veranderd???

Die is helemaal op z'n kop gegooid.. In plaats van appart shaders is er nu een unifed shaders architecteur gekomen.. beetje beter lezen (en ook de bechmarks pagina)

[Bartjuh]

zakelijke quadro lijn (niet quattro)

[Anoniem: 194400]

Aha, dus binnenkort krijgen we ook Folding@Home voor nVidia kaarten? Ik heb nu sinds enkele dagen de Folding@Home client draaien met mijn X1900 XTX, wat opzich goed bevalt. Natuurlijk help ik graag een handje mee aan het folding project, het enige nadeel vindt ik wel dat mijn PC meteen 50 watt meer nodig heeft.

[Milmoor]

Kan je hem niet via een profiel bij het draaien van Folding@Home wat rustiger aan laten doen? Lager voltage, lagere frequentie, en daardoor minder verbruik. Het zijn de laatste loodjes die de bulk van het vermogen trekken.