'Twintig procent betere processorprestaties mogelijk met gpgpu'

Processors met zowel een cpu als een gpu aan boord zouden een stuk sneller kunnen worden, zo stellen medewerkers van de universiteit van North Carolina. Samenwerking van cpu en gpu zou een snelheidswinst van 20 procent opleveren.

Zowel AMD als Intel maken al enige tijd processors met zowel een of meerdere cpu-kernen als een gpu aan boord. AMD's apu's, of accellerated processing units, combineren cpu-kernen met een vrij krachtige gpu met 80 streamprocessors, terwijl Intel zijn krachtiger cpu's met een ingebouwde gpu versmelt. De samenwerking tussen de cpu en de gpu is echter nog verre van optimaal, zo stellen de Amerikaanse onderzoekers, en de prestaties zouden beter kunnen.

De details van hun methode publiceren onderzoeksleider Huiyang Zhou van de universiteit en zijn medewerkers pas eind februari. Wel claimen ze in hun tests een prestatiewinst van gemiddeld 21,4 procent te realiseren, maar voor welk soort taken dit geldt is onduidelijk. Hun methode maakt gebruik van de pre-fetch-capaciteiten van de cpu-cores. Die zouden de rekentaken voor de parallelle processors van de gpu moeten klaarzetten, zodat de gpu efficiënter kan worden ingezet.

Gezien de naam van de paper, CPU-Assisted GPGPU on Fused CPU-GPU Architectures, geldt de snelheidswinst vooral voor gpgpu-geschikte taken. Het onderzoek zal worden toegelicht tijdens het International Symposium on High Performance Computer Architecture, wat een alledaagse toepasbaarheid van de ontwikkelde techniek wellicht wat minder waarschijnlijk maakt. Het onderzoek is gesponsord door de National Science Foundation en AMD.

Reacties (33)

[vinx77]

De laatste zinnen maken het niet duidelijker. Ja, het gaat om het versnellen van GPGPU (OpenCL) door gebruik te maken van snellere data-kanalen via L3-cache-prefetching en daarmee de latency naar beneden te krijgen. Er is veel vergelijkbaar onderzoek gaande naar het mixen van diverse soorten cores (vector-processors zoals in de GPU, RISC zoals ARM, X86) en OpenCL is een hele gangbare methode om de extra processorkracht te kunnen gebruiken. Tevens komen er meer bibliotheken beschikbaar die geoptimaliseerde OpenCL-routines direct beschikbaar stellen aan de programmeur.

Een uitgebreider, beter artikel over dit onderzoek is te vinden op http://arstechnica.com/bu...nd-gpu-to-collaborate.ars

[mad_max234]

De geschiedenis herhaalt zich weer keertje.
Net als nu floating points nu automatisch naar FP unit gaan, zal stukjes code straks automatisch naar de gpu unit gaan die versmolten zit in de cpu kern, niet zoals nu maar echt deel van de cpu is geworden. FP werd namelijk eerst gewoon door de cpu gedaan, via software algoritme. Later kwamen er losse chips(net als de GPU) als coprocessor, bijvoorbeeld de AMD 9511. Later versmolt die twee samen tot één chip, datzelfde gebeurd nu weer met de gpu coprocesor, is de logische vervolg stap die ze steeds maken om alles kleiner en compacter te krijgen.

Pakte FP unit als voorbeeld omdat het ook een coprocosser is geweest zoals de gpu nu was/is in zekere zin. Maar dat intergeren is al bezig vanaf de dag dat computer geboren is, nog voordat de cpu zelf geboren was.

Deze ontwikkeling stond al jaren gepland, amd heeft dit vanaf 2005 al zo nu en dan laten vallen dat ze deze weg wilde inslaan, was eigenlijk ook een onvermijdelijke stap als je kijkt naar de geschiedenis van CPU's en IC in het algemeen. Alles word gecombineerd en geoptimaliseerd/versnelt

[South_Styler]

Deze APU's worden (denk ik) de toekomst, vooral in low budget computer systemen en laptops. Videokaarten zijn straks alleen nodig (of nu ook al in enige mate) om games af te spelen. Een HD 3000 heeft tegenwoordig genoeg power voor een HD filmpje af te spelen.

Ik ben benieuwd naar het Symposium. Er wordt in ieder geval een snelle vooruitgang geboekt!

[Croga]

AMD's APUs hebben al genoeg power om spellen op redelijk detail te spelen. Videokaarten zijn straks alleen nog nodig om high-end games te spelen. AMD's E450 is al in staat om spellen als World of Warcraft op 1920*1080, laag detail te spelen.

[sjekneck]

Wow stamt uit 2004, ik vind het nog niet heel hoopvol om dat te kunnen spelen op lage settings imho.

[simen]

Jah, maar de huidige versie van WoW is niet hetzelfde spel als wat in 2004 uit kwam. De texture resoluties zijn gigantisch verhoogd sindsdien. Ook de polycounts, shaders, particles zijn allemaal vele malen verhoogd/vernieuwd.

Ik hoor je al denken "maar dat maakt het geen nieuwe game/engine". Maar zoek er voor de grap eens screenshots bij uit 2004 en vergelijk ze met wat je nu van Cataclysm en Mists of Pandara ziet. Het verschil is veel groter dan hoe je het misschien herinnert. De systeemvereisten verhogen ook bij iedere expansion.

Kortom; als jij je (toendertijd High-end) Pentium 4 / 1gb ram / Geforce 5800 uit 2004 nu wilt gebruiken om mee te raiden zul je het met 3 frames per seconde moeten doen.

[Znorkus]

Hmhm, ik heb een AMD Phenom II 955 BE op 3.5ghz, met een MSI geforce GTI560-TI, met SSD, hetgeen toch redelijk bij de tijd genoemd kan worden. Met de meer recentere delen in wow (Nagrand, Grizzly Hills, Mount hyjal) duik ik op 1980-1200 ultra toch onder de 40 fps als het zicht in de verte goed is. Dit is op te lossen door grass clutter etc lager te zetten dus daaruit trek ik de conclusie dat het werkelijk GPU-belastend is.

Dat maakt wow een veeleisender spel dan de meest recente need for speed The Run, die op dezelfde hardware absoluut geen krimp geeft (op 1980-1200 alles ultra).

[Reactie gewijzigd door Znorkus op 28 juli 2024 12:24]

[Verwijderd]

Dat je FPS een duik neemt in sommige gebieden in WoW komt niet omdat WoW er zo mooi uit ziet, maar omdat de rek helemaal uit de engine is.

Kijk maar eens wat andere games doen met dezelfde hardware.

[SG]

Rek uit de engine?
Wat een BS.

Wat Crysis deed met DX9 was al top.
Dus wat doet een "nieuwe" engine.
Die is vooral niet nieuw maar hetzelfde ding dat heet code reuse uit hun codebase.
En specifieke delen worden herschreven en eventueel nieuwe features toegeoegd.
Of uitgebreid.

Als er krachtigere hardware uitkomt dan hoefd er niet meteen aan de game engine gesleuteld te worden.
De game content kan dan zwaarder. Dat geefd juist het grootste GFX effect.
Mainstream heefd meer vidmem dus meer textures en of hoge res textures.
Geometry kan ook complexer.
NExt gen API maken vaker eerder de dev gemakkelijk dan dat het opvallende features bied. Vaak is de GFX maar subtiel verbeter door een effect dat de GFX iets wat verfijnd.
Maar wat de gemiddelde gamer niet direct opvald.
Nu met DX11 is er zoiets als Testallatie engine dus gamers met krachtige GPU kunnen opeens stuk meer geometry in bepaalde objecten verwachten.

Dat kan wat meer opvallen afhankelijk in wat voor mate en waar dat toegepast wordt..

Dus rek, Je maakt gewoon veel zwaarder en complexer en gedetaileerder content met dezelfde engine.

[Dorstlesser]

Neem me niet kwalijk, maar ik geloof dat met 'engine' hier niet DX oid wordt bedoeld. Crysis runt op de CryEngine 2.

En gast! Let op je spelling! Je boodschap komt echt niet over in dat woud van spelfouten!

[Verwijderd]

Idd, de engine is er niet op gebouwd en er nog minder op voorzien om zo'n Hi-Def beeld op je scherm te toveren, daarom is het ook wat meer belastend voor de computer.

En voor zover ik me herinner is WoW ook wel een redelijk CPU-intensieve game?

[rob12424]

ik heb een amd a8 en met empire total war de oorlogen tegen een stad bijvoorbeeld schokt soms nogal bij veel eenheden met alle detail op normal! rts games zijn op zich gezien zwaarder dan fps enz. omdat er op meerdere delen dingen te zien zijn die anders zijn!

Overigens dat de a8 dit niet aan kan ligt eerder aan de drivers want sie schijnen nog niet optimaal met windows te werken.

[Ample Energy]

De E450 is dan ook al vrij oud en is behoorlijk gehaast uitgebracht. Toen stonden APU's nog in de kinderschoenen. De nieuwste Fusions kunnen meerdere schermen tegelijk aansturen en games uit 2011 met hoge resoluties en mooie settings aan.

[Seth_Chaos]

Als je in je achterhoofd houdt dat vrijwel elke fabrikant waaronder Intel, Nvidia en AMD hele divisies achter gesloten deuren laten werken aan de toekomst van cloud computing en cloud gaming vindt ik dit nog niet zo raar klinken.

De APU's zullen steeds meer de standaad GPU's en CPU's in consumenten electronica verdringen simpelweg omdat er niet meer rekenkracht vereisd is in consumenten electronica. En aan de cloud kant zal de APU de CPU en GPU steeds meer verdringen omdat het kosten efficienter is een cluster APU's te gebruiken dan afzonderlijke CPU's en GPU's.

[humbug]

APUs zullen niets verdringen. Wat je wel zult zien is dat CPUs met ingebouwde GPUs sneller en sneller worden. Je weet wel de i3,5 en 7 van Intel, Tegra van Nvidia en de CPUs van Apple, Samsung, Marvel, Quallcomm en nog vele anderen die AMD voorgegaan zijn bij deze integratie.

APU is een irritante marketing term waarmee AMD probeert te doen alsof men iets nieuws bedacht heeft terwijl men gewoon als laatste in de rij aansloot.

(En weer 2 cent armer)

[TERW_DAN]

Een HD 3000 heeft tegenwoordig genoeg power voor een HD filmpje af te spelen.

Zo heel spannend is dat nu ook weer niet. Ik speel HD spul af met een GMA4500MHD icm een 1.2GHz singlecore Celeron 723 zonder problemen.

[Ample Energy]

Tja, een Raspberry PI kan ook 1080p afspelen, maar die ga je ook echt niet gebruiken voor een HTPC. Een GMA4500 of HD3000 kan geen blu ray op 1080p afspelen. Die kracht mist echt nog en daar heb je de nieuwste APU's voor nodig.

[Verwijderd]

Raspberry Pi kan je ook gebruiken als mediacentertje of HTPC hoor... XBMC draait er zo ongeveer perfect op, alle Full-HD films die op h264 codec encoded zijn, kan ie zonder problemen afspelen. Kijk anders even naar het voorlaatste artikel over de RPi hier op tweakers.

[Ample Energy]

Ik zeg toch dat-ie 1080p kan afspelen?
Ik zeg alleen dat je hem niet als HTPC kunt gebruiken, omdat niemand 500 MB 1080p films download. Die showen ze namelijk in dat artikel, ze laten geen hoge kwaliteit films zien en ze gaan echt geen blu ray (waar ik het over had) afspelen. Een blu ray heeft over het algemeen een bitrate van 20-30 MB/s. Die film die ze showden 0.06 MB/s of zo? Daarom kan je een Raspberry PI niet gebruiken als HTPC, het is meer een leuk voorbeeldje van de mogelijkheden van zo'n klein en goedkoop pc'tje.

[Reactie gewijzigd door Ample Energy op 28 juli 2024 12:24]

[Nibbz]

Is die film in de review (die met dat konijn) ook niet maar een paar minuten lang? Dan komt de bitrate aardig overeen en zit het verschil hem alleen in de lengte van de video/hoeveelheid mb.

Want zover ik weet zijn die Raspberrys zo vet..omdat ze high quality vids dus wèl goed afspelen.

[Bulkzooi]

Als MediaCenter op basis van XBMC kan de RaspberryPI nog lang niet tippen aan de x86 architectuur. De GPU is enkel krachtig genoeg voor low-bitrate H.264 spul. Ander spul zal veelal softwarematig gedecode moeten worden en de ARM11 CPU gaat niet veel verder dan SD-content (vergelijkbaar met de omgebouwde Xbox mits XBMC betere support krijgt voor de hardware).

Deze Broadcom/Davilla combo. zorgt er wel voor dat, middels de BCM2835, GPU decoding voor ARM11 (via openmax) naar XBMC gebracht wordt.

XBMC en de ARM GPU drivers dienen nog flink geoptimaliseerd te worden en dan nog is het wachten op de volgende generatie ARM's die beschikken over een krachtigere GPU en in ieder geval kunnen terugvallen op een betere CPU. Maar de software ondersteuning van XBMC en Linux ecosysteem moet ergens (goedkope apparaten, een buzz maar toch net niet wat we zouden willen) beginnen....

De volgende stappen (OMAP en ARM7 support) maken ARM pas geschikt voor mainstream HTPC/XBMC gebruik. Deze hardware is er al maar het is even wachten op een killer-combo CPU/GPU en een bedrijf zoals RaspberryPI dat het in de markt zet.

[Reactie gewijzigd door Bulkzooi op 28 juli 2024 12:24]

[Cytex]

Je hebt waarschijnlijk gelijk, iig voor low budget en vooral voor (non ((heavy))gaming) laptops. Maar aangezien de markt voor videokaarten nog aantrekkelijk is voor bedrijven zal (denk ik) nog wel even verder ontwikkeld worden. Denk dat voorlopig de videokaarten een (kleine) voorsprong zullen hebben.

edit: typo

[Reactie gewijzigd door Cytex op 28 juli 2024 12:24]

[dwarfangel]

Zeker als straks games etc per stream worden aangeboden.

dan heb je geen monsterlijke SLI opstelling nodig voor optimale performance.

[karstnl]

De laatste zin van het artikel is geweldig, ik hoop alleen dat het niet af doet aan de onafhankelijkheid van het onderzoek.

Het onderzoek is gesponsord door de National Science Foundation en AMD.

[Tenocticatl]

Niet noodzakelijk in ieder geval. Het is natuurlijk ook nuttig voor AMD om te weten waar ze nog dingen kunnen verbeteren.

[Tk55]

Er wordt niet specifiek vermeldt dat AMD goed is of Intel slecht en prestatieverbeteringen zijn nooit erg toch?

[Astennu]

Tja dat zal vast en zeker duidelijk worden zodra het gepubliceerd wordt. Maar AMD staat niet echt bekend als een bedrijf wat dat soort dingen uithaalt. Ik weet wel dat ze al jaren investeren in bedrijven die computing in het algemeen willen optimaliseren.

Volgens mij wordt het princiep om een CPU taken te laten klaar zetten voor een GPU al vaker gebruikt. Daardoor kan een GPU veel sneller zijn werk doen. Ik weet alleen niet meer waar ik het gelezen heb. Volgens mij ging het over folding op GPU. En dat je daar een relatief snelle cpu voor nodig had als je een high end GFX kaart had.

[NESFreak]

Nu nog wachten op compilers waar je AMD fusion gewoon als optimalisatie optie kunt meegeven (net zoals optimaliseren voor SSE). Het probleem is momenteel dat je code niet zo snel te porten is van gewoon C++ naar iets wat je GPU vreet. En dan zit je ook nog met libraries die er ook gebruik van moeten gaan maken.

[PhoenixT]

Dat is er al: C++ AMP van Microsoft (samenwerking met AMD en Nvidia). Het is niet simpelweg een compiler-setting, maar dat zal er misschien ook nooit komen. Dit komt in ieder geval het dichtste bij

[computerjunky]

jaen als de software gewoon volledig gpgpu gaat ondersteunen en dus de losse videokaarten het werk van de cpu gaan doen kan het in sommige gevallen wel 10x of meer sneller worden helaas is software optimilisatie de afgelopen 10 jaar een mythe geweest.

veel software snapt 2 cores nog niet eens laat staan gpgpu...

[SG]

Je snapt dnk het pobleem niet zo goed.
Een GPU heeft enkele tot vele honderden cores.

Een aplicatie ka tot enkele tot dozijn taken splitsen.
Maar dan heb je tot 12 Compute shaders van 1000 in gebruik.

Dit is zo makkelijk niet. Veel aplicaties zijn niet van nature concurrent en vele maar beperkt. Er zijn uitzondering die kunnen zelfs extreem op schalen maar meeste doet dat maar beperkt.

Je moet dus verdelen in taken dat is de easy way maar zeer beperkt. En dan de zware taken splitsen in erg veel kleine reken taakjes.

Nu is er zoiets als code afhankelijk heid dat meer of minder aan wezig is. En dat houd de boel juist tegen.

[computerjunky]

een electrische auto maken die 500 km op een volle accu rijdt is ook niet zo makkelijk maar als ze het nooit proberen hebben we over 20 jaar alleen nog maar een fiets voor lange afstanden...

het zal best lastig zijn maar als de standaard niet uitgewerkt word gaat het er nooit komen ondanks dat het de toekomst moet worden (zoveel rek zit er niet meer in cpu only ontwikkelingen).