Stanford University zet GPU in als co-processor

Onderzoekers van het Stanford University Graphics Lab zijn er in geslaagd om de kracht van moderne DirectX 9.0-videokaarten voor andere zaken te gebruiken dan het renderen van 3d-graphics. Het concept van een videochip waarop programma's (shaders) kunnen worden uitgevoerd is alweer een aantal jaar oud, maar men is er nu in geslaagd om deze kracht ook voor niet-3d-ontwikkelaars toegangelijk te maken middels een aantal libraries en compiler. Code geschreven in BrookGPU kan hiermee draaien op een moderne Radeon of GeForce. BrookGPU is een uitbreiding op C gebaseerd op het door dezelfde universiteit ontwikkelde Brook, een taal voor supercomputers die veel met parallelle datastromen werken. Precies de strategie die een GPU ook volgt. Sponsors als nVidia, ATi, IBM en Sony zagen er daarom wel brood in om de mogelijkheden van generieke programma's op videokaarten nader te laten onderzoeken.

Volgens de persoon die het verhaal naar Slashdot stuurde kunnen de shaderunits van een GeForce FX 5900 Ultra maximaal 20 gigaflops halen, prestaties waarvoor de Intel Pentium 4 naar 10GHz geklokt zou moeten worden. Daarnaast profiteert een GPU natuurlijk van een enorme hoeveelheid geheugenbandbreedte. Er moet wel bij verteld worden dat lang niet ieder programma geschikt is om vertaald te worden naar de zeer specifieke architectuur van een videokaart. De ontwikkeling opent echter wel de deur voor een aantal interessante nieuwe toepassingen in de toekomst, de huidige generatie videochips is namelijk nog redelijk inflexibel vergeleken met wat er in de toekomst verwacht wordt. Een samenwerking tussen een centrale processor voor het normale werk en een videochip als co-processor om grote hoeveelheden data per seconde te verwerken is door dit onderzoek in ieder geval een stap dichterbij gekomen.

Reacties (72)

[curry684]

Al die mensen die hier zitten te roepen over dat dit in de toekomst de computers zoveel sneller gaat maken en dat OS'en dit native moeten gaan doen: lees deze quote nog eens:

Er moet wel bij verteld worden dat lang niet ieder programma geschikt is om vertaald te worden naar de zeer specifieke architectuur van een videokaart.

Een normaal programma, zeg een willekeurige Word Processor, draait voor 99.99% op integers. Fabriekssoftware is puur integers, hoogstens voor wat ratiobepalingen. Databases haten floats, knuffelen integers. Ik kan ondanks 19 jaar programmeerervaring niet een-twee-drie een Win32 API, XLib of Linux/Unix-functie opnoemen die een float als parameter gebruikt. Ik ken genoeg API-calls die floats als parameters willen, natuurlijk: ze zitten echter allemaal in DirectX en OpenGL.

Buiten Photoshop, encoders/decoders voor lossy bestandsformaten (MP3/MPEG/JPEG) en zwaar wetenschappelijke software (waar dit artikel over gaat) is de haalbaarheid van ruimere inzet voor deze techniek nul komma nul.

Waarom dacht je dat GPU's zoveel MFLOPS halen in vergelijk met een P4? Omdat de P4 brak ontworpen is? Dacht het niet, dat is omdat de GPU voor 99% leunt op floats en de P4 FPU in dagelijks gebruik zelden tot nooit de remmende factor kan zijn in een gemiddelde applicatie. De GPU is geoptimaliseerd voor float operaties, de P4 voor integer en memory operaties.

Het zijn 2 verschillende beestjes, en voor heel specifieke toepassingen kan de extra FPU-power nuttig zijn. Maar echt niet voor je koetjes of je webbrowser.

[Techless]

Het moet best mogelijk zijn om dit native te maken. Zo'n GPU is eventueel rekenkundig genoeg om een programma te draaien om een pc virtueel voor te stellen (een vmWare a la GPU).

Daarnaast staat de ontwikkeling van de GPU ook niet stil. De architectuur van deze kan toch veranderen, zodat het deze functie ten goede komt. Het is immers een mogelijkheid om de pc efficiënter te maken en dat is nooit weg. Energie wordt er niet goedkoper op!

Bedenk ook eens dat in 1997 de GPU alleen rendering voor zijn rekening nam, in 1998 kwam daar triangle setup als taak bij. Anno nu wordt lightning en transformation ook door de GPU verzorgd. De CPU is alleen nog verantwoordelijk voor de scene berekening en applicatie taken van het 3D proces. Het lijkt mij een logische ontwikkeling als de GPU die twee taken in de toekomst ook gaat vervullen. Dan is het nog maar een kleine stap om ook andere applicaties op de GPU uit te voeren.
Uiteraard moeten die er dan wel voor geschreven zijn, maar dat is nu ook al zo voor applicaties die gebruik maken van de GPU (of in ieder geval die onderdelen van het proces die van toepassing zijn). En wie weet kan het gebruik van een emulator uitkomst bieden.

Geef het wat tijd, moet je kijken wat ze dan kunnen.

[curry684]

Het lijkt mij een logische ontwikkeling als de GPU die twee taken in de toekomst ook gaat vervullen.

Mij lijkt dat echter helemaal geen logische ontwikkeling, en wel om wat ik daarboven zei dat de GPU zijn rauwe kracht hoofdzakelijk onttrekt aan het feit dat hij geoptimaliseerd is voor 1 simpel doel. Zodra GPU's aan random memory access, integerrekenwerk en andere typische CPU-taken moeten gaan doen moet er een CPU-architectuur omheen komen. GPU's hebben buiten de geoptimaliseerde shadertalen geen instruction pipeline, geen L1-cache, weinig tot geen branch prediction. Dat heeft ie ook allemaal niet nodig, het zou hem ook remmen. Maar als je het er wel op gaat zetten heb je gewoon een P4 als GPU die nog maar 2.5GFlops haalt ipv 20.

Dan is het nog maar een kleine stap om ook andere applicaties op de GPU uit te voeren.

Het zou volkomen onzinnig zijn om die stap te maken. Als je dan meer CPU power wil: zet er dan een CPU bij die wel volledig voor z'n taak geschikt is.

[Daro]

Zover ik weet is een float een variabele met een veel groter bereik:

type:........bytes...min.....................max
int:...........2.........-2147483648........2147483647
float:........4.........3.4 E-38...............3.4 E+38

Als je dus je programmatuur aanpast dat alle int float wordt, kun je die GPU wel gebruiken, en zijn FPU prestaties.

Misschien heb je ik je posting verkeerd begrepen, maar met mijn geringe programmeerervaring (1 jaar ), denk ik dat het best makkelijk is om int naar float om te zetten.

[The Bad Seed]

Zover ik weet is een float een variabele met een veel groter bereik:

type:........bytes...min.....................max
int:...........2.........-2147483648........2147483647
float:........4.........3.4 E-38...............3.4 E+38

Als je dus je programmatuur aanpast dat alle int float wordt, kun je die GPU wel gebruiken, en zijn FPU prestaties.

Spijtig genoeg klopt dat niet.
Het bereik van een float is inderdaad groter dan van een int, maar een float is niet zo nauwkeurig. De float representatie van 100000000 is identiek aan die van 100000030 (01001110011011100110101100101000 volgens de IEEE754 standaard), terwijl dat bij een int niet het geval is.


Deze onnauwkeurigheid komt door de wijze waarop een float binair gerepresenteerd wordt.
Een float wordt voorgesteld door +-(1.abcdef...) x 2^y
waarbij in abcdef...(=de mantisse) elke letter 1 bit voorstelt (totaal 23 bits) en y 1 byte(bereik -126 tot +127), +of- is ook 1 bit. Totaal = 32bits of 4 bytes.

Zie bijvoorbeeld http://people.uncw.edu/tompkinsj/133/numbers/Reals.htm

[Cergorach]

Ik ga er van uit dat ze ook best wel eens gebruikt kunnen worden voor het renderen van 3D scenes. Aangezien de GPU het normaal in realtime doet, lijkt het me logisch dat deze ook kan worden ingezet tijdens het niet realtime renderen van 3D scenes...

[curry684]

Ik ga er van uit dat ze ook best wel eens gebruikt kunnen worden voor het renderen van 3D scenes. Aangezien de GPU het normaal in realtime doet, lijkt het me logisch dat deze ook kan worden ingezet tijdens het niet realtime renderen van 3D scenes...

Ik noemde games ook niet als mogelijke toepassing van deze techniek omdat me dat net zo duidelijk leek als renderingsoftware Eigenlijk alle renderprogrammatuur waar ik ooit mee heb gewerkt gebruikt DirectX en/of OpenGL om renderwerk te laten verrichten door de GPU, het grootste probleem van de GPU is dat die niet geschikt is voor de raytracing technieken zelf (true lighting) en echt speciale textureeffecten.

[imagica]

Juistem, en een goed voorbeeld is bijvoorbeeld de Special Effects in Premiere en Holywood FX om maar een dwarsstraat te noemen, deze effecten zijn vaak realtime te doen in b.v. games middels goede code, echter in bovengenoemde software duurt dit zelfs op highend systemen vaak (onnodig) lang qua rendertijd, dit soort plugins zouden een stuk sneller zijn middels de GPU te gebruiken ....

[T.T.]

Zie ook GPGPU. Deze website draait helemaal om het principe van programmeerbare GPU's.
De doorbraak is dat nu iemand een redelijk eenvoudige compiler heeft gemaakt die voorkomt dat je je als programmeur met de details van de gpu's moet bezighouden.

Enkele onderwerpen (niet direct graphics-gerelateerd) die voorbijkomen:
- Real-Time Cloud Simulation
- fast Fourier transform
- Dense Matrix Algebra
- Multigrid Solver for Boundary Value Problems

De vergelijking met een 10 GHz Pentium4 is overigens niet zo makkelijk te maken:
Dit is alleen waar voor heel specifieke taken waarvoor de GPU is geoptimaliseerd. De Pentium4 is een algemene processor die veel meer taken moet uitvoeren dan de huidige GPU's. De trend is dat GPU's steeds meer normale processors worden. Één van de mogelijkheden is dan ook dat we op den duur weer op één centrale processor uitkomen (waar we ook mee zijn begonnen voor 3dfx etc).
Een gespecialiseerde GPU is ongelooflijk snel in maar een heel klein aantal toepassingen. De uitdaging is nu om te proberen de GPU parallel te gebruiken en dan de bewerkingen die de GPU snel doet daarheen te verplaatsen. Programma's moeten dan wel opnieuw gecompileerd worden en dat zal niet zo makkelijk zijn (understatement). Denk alleen maar aan latency naar de videokaart die je niet hebt wanneer je alleen binnen de cpu blijft. Vooral programma's die veel getallen met elkaar vermenigvuldigen (matrix en vector vermenigvuldigingen) lijken me geschikt, misschien dpc en wat compressietechnieken? Je wilt bovendien niet dat na elke berekening weer communicatie met de cpu nodig is, dan zorgt de latency ervoor dat er van snelheidswinst geen sprake is.

Why is Graphics Hardware so Fast?
Interessante presentatie bij dit onderwerp.

[Munters]

Klopt helemaal en daarbij komt ook dat de GPU power alleen inzetbaar is wanneer deze niet voor normale beeldzaken nodig is.

Ik ben bang dat dit een leuk projectje is, dat vrij snel achterhaalt zal zijn. De GPU inzetten voor massaal parallelle berekeningen is leuk, maar concurreert gewoon met de ingebakken SSE in de processor.
Dus niks P4 op 10Ghz, maar gewoon SSE3 en het is weer einde project.

[Verwijderd]

Een P4 is een general purpose CPU. Een GPU is specialistisch en kan voor bepaalde toepassingen al gauw 10-100x sneller zijn. Een P4 kan dat nooit inhalen zonder dat de GPUs bijbenen. Het is immers veel makkelijker de GPU die berekeningen op hoge snelheid te laten doen dan een generieke x86.

[Microkid]

Cool! Als ze nou die rekenkracht wat algemeen beschikbaar maken, dan wordt het encoden van MPEG2 streams een fluitje van een cent. Dat is nl. pure rekenkracht die je mooi van de GPU kan "lenen". Of denk eens aan koetje, Seti, enz enz.
Of what about : renderen van video streams in bijv. Premiere of Pinnacle Studio?
Ik zie zat toepassingen en zit nu al te kwijlen.... ;-)

[familyman]

Zou toch moeten kunnen. Zit in ieder geval buitenlangs beschouwd toch een parallel tussen MPEG-2 en videokaarten ;-)

Wil ik ook!

Elke keer als mn proc het niet meer redt, knal je gewoon een nieuwe videokaart in je PC. Zo krijg ik die sloten ook nog vol. Wel even dringen, alle aansluitingen in PCI-brackets en die videokaarten. Leuke nieuwe mod: ATI 9800XT zonder videoout, maar met 2x firewire, 2x USB en een CCFLcontroller.

[0rbit]

CPU's zijn nog altijd meer geschikt en goedkoper voor het uitvoeren van x86 code dan GPU's hoor. Tja, dat je Winamp equalizer (uit dat ding; koop een fatsoenlijke versterker) zijn FFT via de GPU kan uitrekenen... lekker boeiend...

[nika]

Betekent dit nu de terugkomst van de coprocessor op het moederbord.

Ik vindt het nogal wat dat een P4 naar 10GHz geklokt moet worden om eenzelfde aantal gigaflops te halen. Daarnaast is de hardware-software combi met zo'n videokaart natuurlijk verre van optimaal. Welke prestaties kunnen worden bereikt als er een voor dit soort operaties geoptimaliseerde chips op de markt worden gebracht?

[Gyske]

Een tijdje terug was er een nieuwe coprocessor in het nieuws: http://www.tweakers.net/nieuws/29240 .
Deze zou volgens het artikel in o.a. een x86-systeem geïntegreerd kunnen worden en capaciteit van 25,6 GFLOPS hebben, en doorbij slechts 2,5 Watt verbruiken(!). Best leuk als je die bij een distributed project zou kunnen inzetten.

[Verwijderd]

Ik heb er nog nooit bij stilgestaan, maar ik wist niet dat er data van de videokaart terug naar de northbridge gestuurd kon worden.

Indien dat nu reeds gebeurt, in welke gevallen is zoiets dan nodig?

[familyman]

Heb dat niet ook wat met AGP apture size te maken? Misschien het cachen van texturetjes etc.

[Wouter Tinus]

Bijvoorbeeld voor videocapturing .

[Verwijderd]

Ik kan zo ook weinig bedenken behalve het maken van screenshots of het opslaan van de state van de GPU voor schakelen tussen programma's.
Maar het kan als sinds de eerste hercules videokaarten dat teruglezen van frame buffer data.

[Verwijderd]

of het renderen van een scene naar een texture door videokaart en vervolgens het bewerken van het resultaat door de CPU. gebeurt ook weleens.

[ritsjoena]

Als je data kunt terugsturen kun je functies die de grafische kaart niet ondersteunt alsnog door de CPU laten doen. Zal tegenwoordig minder voorkomen dan vroeger omdat de niet ondersteunde functies meestal te veel CPU kracht vergen, maar toch.

Daarnaast kun je harde schijf en geheugen als extra cache gebruiken voor het verwerken van te grote frames.

Screen-capturing is al genoemd. Maar wat dacht je van video-bewerking mbv de grafische kaart. Dan wil je het resultaat kunnen opslaan.

[Verwijderd]

Wat is er mis met een PCI kaart vol met DSP's?
Die hebben een nog grotere FLOP prestatie.
En zijn ook prima parallel te gebruiken.
Die zijn er ook op de markt incluis de nodig API's.

Lijkt mij een beetje moeilijk doen terwijl dat niet hoeft. Maar ja, daar zijn universiteiten voor.

[Wouter Tinus]

Wat is er mis met een PCI kaart vol met DSP's?

Dat niemand ze heeft en niemand ze gaat kopen zolang hun software er geen gebruik van kan maken. Anderzijds gaan makers van die software niet proggen voor zulke exotische hardware. Daarentegen zullen DX9-videokaarten over een paar jaar vrij standaard zijn .

[I.R. Overclocked]

Voor audio editing is bijvoorbeeld de TC-powercore redelijk bekend.

PowerCore Firewire offers the same unique architecture as PowerCore PCI, featuring a Motorola PowerPC and 4 Motorola DSPs for unsurpassed flexibility and quality. All signal processing is performed on the PowerCore unit, freeing up precious host performance resources for virtual instruments or native Plug-Ins.

Specifications (Excerpt)

4 x Motorola 56K DSPs running at 150 MHz
512kWords of SRAM per DSP
1 x Motorola PowerPC running at 266 MHz
8 MB DRAM for the PowerPC
3 FireWire pass thru connectors (to connect more than one device on one bus)
400 MBit Firewire Connection

[Professor_Botje]

Paralelle we hebben het nog niet gehad over 25 VooDoo2 kaartjes paralelle in SLI

[Verwijderd]

Bestaan die dan niet?
Er zijn renderkaarten op de markt die eigenlijk niets anders doen dan je cpu aanvullen als je op je 2D/3D werkstation gaat renderen.
http://www.artvps.com/products.ihtml?page=pureoverview
zo'n kaartje dus. Maar je kan dan wel rekenen op een prijskaartje van een slordige 3000euro.

[memphis]

Het idee om de videokaart meer te laten doen is niet nieuw. Vroeger (in de DOS tijdperk) in de wedstrijden om zoveel mogelijk basismemory vrij te maken werd ook vaak een stukje videomemory meegenomen waardoor de 640k grens wel eens tot 900k haalbaar was

[Munters]

Dat was ook vrij gebruikelijk op de eerdere machines als de C64, TRS, MSX etc.
Maar het is wat anders dan waar het hier over gaat. Daar werd alleen het specifieke video en memory-mapped I/O geheugen gebruikt voor algemene zaken. Dit artikel gaat over het inzetten van een co-processor voor algemene zaken.

[leuk_he]

Vroegah,

De ti/99/4a (homecomputer) had 16 KB geheugen. Dit was Video geheugen. Deze computer had standaard 16 Kb video ram geheugen en 256 bytes "echt"geheugen. Dat waren nog eens tijden.

[Kurgan]

Hmmm, krijg je straks computers met twee videokaarten: eentje voor het beeld, eentje als coprocessor...

[I.R. Overclocked]

Misschien grappig bedoeld, maar het kan wel een hele simpele manier van upgraden zijn. Gewoon een snelle PCI videokaart kopen, en je PC word een stuk sneller.

[Kurgan]

Mits je de juiste software hebt, ja. Misschien iets voor toekomstige OS-en: de workload flexibel verdelen over CPU en GPU?

[utbone]

Een GPU als extra Co processor is leuk, maar als deze continue full load aan het werk is, dan zal de stroom toevoer nog veel hoger worden. Bij een zware game hoor je de voeding al een tandje harder lopen.

[Mentalist]

En nu heb je een dikke Geforce/Radeon in je PC zitten die vrijwel niets doet tijdens het koetje/DivX/etc. Is dat zoveel beter dan?

Dat is het 'm juist, door dit soort dingen word geprobeerd alles uit de pc te halen wat erin zit. En dan koop jij gewoon een wat zwaardere voeding en dan zijn we allemaal tevreden

[familyman]

Heb ff naar de site gekeken, maar het werkt expliciet met Ati kaarten ook. Sterker, op die site noemen ze eerst Ati en dan pas nvidia.

Overigens, het lijkt me dat met benchmarks op basis van dit principe het veel beter te bepalen is wat de brute rekenkracht van de videokaaart is. Het zal niets zeggen over de kwaliteit van de directx implementatie (hoe rendered ie fog enzo), maar het is zeker niet te truuken.

[Verwijderd]

Het zou hoogstens wat zeggen over een de performance van de shaders. En dan nog niet eens de complete shaders maar enkel dát deel dat specifiek voor dergelijke generieke doeleinden gebruikt kan worden, het grootste deel van de shadertaal is namelijk expliciet gericht op graphics.

Net zoals die GFLOPS rating niet veel zegt; als deze enkel voor de primitieve operators gebruikt kan worden zoals deze op die site genoemd worden kan je maar een deel van je berekening tegen die snelheid uitvoeren, de rest moet alsnog via de CPU.

Beschouw het als een coprocessor die alleen maar NAND operaties kan uitvoeren; die zal ook makkelijk in de TeraFLOPS perfomance lopen alleen je gebruikt het niet zo vaak