Hoofdcategorieën
Device Settings

[RSS] [quick] Index » Reviews » Core » Hardware » Gpu's & Videokaarten » Larrabee: op het kruispunt van gpu en cpu » Conclusie

Larrabee: op het kruispunt van gpu en cpu

Door Wouter Tinus, donderdag 14 augustus 2008 11:40, views: 67.424

Conclusie

Larrabee is zonder twijfel een van de interessantste chips die Intel ooit ontwikkeld heeft. Het is een antwoord op Niagara, de Cell en de (gp)gpu in één en dat allemaal zonder af te wijken van de oude vertrouwde x86-standaard.

Maar hoe gaat Larrabee er in de praktijk uitzien? Geruchten spreken over een videokaart met 24 cores, met een kloksnelheid van 2GHz en een tdp van 150W. Zo'n beest zou op papier 1,5 teraflops aan rekenkracht hebben, 25 tot 50 procent meer dan de huidige top-gpu's. Hoewel het bijzonder lastig is om flops te vertalen naar bijvoorbeeld frames per seconde - zeker met wild verschillende architecturen - moet wel worden opgemerkt dat alle benchmarks die er nu goed uitzien natuurlijk al lang en breed gedegradeerd zijn tot de middenmoot tegen de tijd dat de Larrabee in 2010 in de schappen ligt. Bovendien blijft de kwaliteit van drivers een zorgenkindje. Intels geïntegreerde producten zijn wat dat betreft nooit super geweest, terwijl echte gamers erg veeleisend zijn.

Het zou echter verkeerd zijn om Larrabee puur te beoordelen op zijn kansen als high-end videokaart. De architectuur zal niet alleen gebruikt worden voor pci-insteekkaarten, maar ook beschikbaar gemaakt worden als losse processor die direct in het socket van een servermoederbord gestoken kan worden. Sta ook niet verbaasd te kijken als Intel binnen een paar jaar zijn eerste heterogene ontwerpen aankondigt, waar bijvoorbeeld vier Sandy Bridge-cores en zestien Larrabee-cores op één 32nm-chip terechtkomen.

Larrabee systeem
Samenvattend lost Larrabee een van de pijnlijkste tekortkomingen van x86-chips op: het tekort aan grote hoeveelheden rauwe flops. Of een Direct3d/Opengl-renderer de geweldigste toepassing is voor de nieuwe architectuur valt nog te bezien, maar zo niet dan weet men er ongetwijfeld wel raad mee voor andere taken die men nu naar een chip als Cell of gpu probeert om te zetten. De vraag blijft echter of Larrabee nog op tijd is om de uittocht te stoppen, maar dat is iets wat Nvidia, AMD en Intel de komende jaren onderling mogen uitvechten.

T'rug naar huus

Inhoudsopgave

  1. Introductie
  2. Pimp my Pentium
  3. Larrabee
  1. Software en schaalbaarheid
  2. Conclusie
  3. Reacties (62)
Advertentie

Lees meer over

Gerelateerde content

Reacties

Flat modeFlat mode Sorteer aflopendSorteer aflopend Moderatie FAQModfaq
Niveaufilter: -1 Ongewenst: 62 reacties zichtbaar620 Off-topic / Irrelevant: 58 reacties zichtbaar58+1 On-topic: 31 reacties zichtbaar31+2 Informatief: 13 reacties zichtbaar13+3 Spotlight: 0 reacties zichtbaar0
«  1  2  »

Door harrald, donderdag 14 augustus 2008 11:54

Score: 0
mooi artikel
ik denk dat er bij 2. Pimp my Pentium een acronym niet is afgesloten ;)

Door petethechop, donderdag 14 augustus 2008 12:15

Score: 0
Klopt :) En wat dacht je van "een agnostische aanpak" in de introductie. Klinkt goed, maar het klopt niet.
Gelukkig heeft hij meer verstand van processors _/-\o_
Erg interessant stuk. Echt bovengemiddeld qua niveau hier op T.net

[Reactie gewijzigd door petethechop op donderdag 14 augustus 2008 12:16]

Door SG, donderdag 14 augustus 2008 18:42

Score: 0
Misschien afgekeken van annand tech article die er al langer staat. Die lijkt mij veel uitgebreider. Maar 'n goede samenvatting van larrabee in NL is mooi megenomen.

Door MBV, donderdag 14 augustus 2008 22:55

Score: 0
Echt waar?
- "zeker met wild verschillende architecturen"
- "Wat dat betekent voor de gemiddelde framerate bij verschillende kloksnelheden en aantallen cores laten we als oefening voor de lezer over."

Wat zou dat zijn geweest? Vast nog wel meer leuke vertalingen te vinden, maar ik heb teveel Engels gepraat de afgelopen tijd ;)

Door TERW_DAN, donderdag 14 augustus 2008 12:02

Score: 2
Zeer mooi artikel.

Ik denk dat dit soort ontwerpen een gigantische kans van slagen hebben, zeker omdat het draaien van veel meer processen parallel aan elkaar zeer interessant is, niet alleen in games, ook OSen kunnen hier mooi gebruik van maken. In games is het natuurlijk duidelijk waar het voor gebruikt wordt. Je wijst gewoon een x-aantal cores toe om bijvoorbeeld de omgeving te renderen, een core voor het renderen van het haar van de hoofdpersoon en 1 core voor het maken van zweetdruppeltjes op het voorhoofd. Zeker als je vele threads naast elkaar kunt draaien is het geen probleem om 3 cores alleen maar grassprietjes te laten renderen, dat dan onafhankelijk gedaan wordt van alle andere zaken in een spel.
Op die manier kunnen andere programma's er ook gebruik van maken. Voor ieder specifiek onderdeel wordt gewoon een aparte core gebruikt.

En op het moment dat er geen verschil zitten in cpu's en gpu's is dit heel goed te schalen.

Door Jogai, donderdag 14 augustus 2008 12:06

Score: 1
Lijkt me dat de cores verdeeld worden aan de hand van de vraag. Ze delen het nu op in tegels maar ik vraag me af wat de cores doen die bijna geen werk hadden aan bv de lucht (aanname: lucht = blauw) te renderen.

Door Wouter Tinus, donderdag 14 augustus 2008 13:02

Score: 1
Een core die klaar is met zijn tegel kan gewoon aan de volgende tegel beginnen :). En als er geen tegels meer zijn voor het frame is het vaak mogelijk om alvast aan het volgende frame te beginnen.

[Reactie gewijzigd door Wouter Tinus op donderdag 14 augustus 2008 13:11]

Door .oisyn, donderdag 14 augustus 2008 13:26

Score: 2
Dat is vaak niet mogelijk, en daarom schalen technieken als alternate frame rendering bij meerdere GPU's lang niet altijd zo goed. Een typische game heeft aan het eind van z'n rendering-slag namelijk nog een zooi fullscreen effects, waarbij de vorige render steeds als input van de volgende wordt genomen. Een tile kan dan dus pas beginnen als alle overige tiles klaar zijn.

Door Wouter Tinus, donderdag 14 augustus 2008 13:38

Score: 1
Zoals ik het begreep lossen ze dat op door die afhankelijksheidsboom bij te houden, zodat delen van volgende frames kunnen beginnen zodra alle data waar ze van afhankelijk zijn klaar is. Hoe ze precies omgaan met fullscreeneffecten weet ik niet, maar zelfs als de hele 'main' render geblokkeerd wordt omdat tiling van zo'n effect niet mogelijk is (zou voor Larrabee absoluut geen optimale situatie zijn, dus ik denk dat ze dat zo veel mogelijk vermijden) dan kunnen er nog shadow maps e.d. gedaan worden.

Door .oisyn, donderdag 14 augustus 2008 22:39

Score: 2
Zoals ik het begreep lossen ze dat op door die afhankelijksheidsboom bij te houden, zodat delen van volgende frames kunnen beginnen zodra alle data waar ze van afhankelijk zijn klaar is
Mja, ik denk niet dat ze dat op dat niveau kunnen doen. Dan moeten ze namelijk kunnen bewijzen dat bijv. texture fetches in een shader nooit buiten een bepaald gebied mogen komen (min of meer de omringende tiles zeg maar), maar bij een gaussian blur waarbij de hoeveelheid blur afhankelijk is van een waarde in de bloom buffer (vaak alpha-component van de framebuffer) moeten ze dus praktisch eerst de shader uitvoeren zodat ze kunnen weten of ze de shader uit kunnen voeren :)

Daarnaast is het niet zo erg als ze even moeten wachten - dat moet de huidige GPU immers ook al in die gevallen. Bij onafhankelijke renders zoals shadowmaps kan natuurlijk wel meteen door worden gerenderd. Overigens worden shadowmaps gerenderd vóór de main scene, dus tijdens fullscreen effects maar wat shadowmaps gaan doen kan niet echt ;) (voor de volgende frame natuurlijk wel alvast, maar daarvoor moet een game teveel vooruit queuen en krijg je een te grote framelag)

Door Jogai, donderdag 14 augustus 2008 12:02

Score: 1
Is Half Life met een andere opzet geprogrammeert? In de grafiekjes wijkt hij steeds af van de andere 2 games. Of heeft intel een niet spannend stuk genomen om te testen?

Door .oisyn, donderdag 14 augustus 2008 13:10

Score: 1
Is Half Life met een andere opzet geprogrammeert?
Ja, hij is namelijk veel minder "next-gen" door erg veel gebruik te maken van precalculated lighting. Dit scheelt erg veel kwa performance, maar het maakt de boel natuurlijk wel minder dynamisch, en daardoor is de lijn in de grafiek vrij stabiel.

[Reactie gewijzigd door .oisyn op donderdag 14 augustus 2008 13:27]

Door NitroX infinity, donderdag 14 augustus 2008 12:16

Score: 0
Of een Directc/Opengl-renderer de meest geweldige toepassing is voor de nieuwe architectuur valt nog te bezien, maar zo niet dan weet men er ongetwijfeld wel raad mee voor andere taken die men nu naar een chip als Cell of gpu probeert om te zetten.
3dfx Glide, S3 MeTaL, etc. WOEI!!!!

Glide games op nieuwe hardware :P

Door SG, vrijdag 15 augustus 2008 07:21

Score: 1
Dat lijkt mij zinloos. En heeft maar een doel.
Oude pure 3DFX games te kunnen draaien.
Dit zou je alleen van die echte harcore 3DFX fans kunnen verwachten die nog steed bij die oude leem blijven. Dus hardware en games. En vanuit die scene iemand opstaat die Glide software renderer voor Voodoo hardware emulatie gaat ontwikkelen.

De massa speel liever nieuwere games.
De Software aanpak zal juist eerder worden toegepast om andere laternatieve render methoden te gebruiken.
Raytracing is blijkbaar favoriet.
Voxel is dan ook goed mogelijk op een hoger niveau omdat er veel meer reken kracht ter beschikking door Larrabee.
Of hybrides met paar van die technieken.

S3 metal is één Feature wat S3 als eerste toepast zoals Matrox in de G200/400 series al bumpmaping als enigste toepast. Met nextgen DirectX en openGL en bijbehorende hardware is dat allang achterhaald. En is zoiets in andere form al standaard in de huidige API's en Hardware

Door TeXiCiTy, donderdag 14 augustus 2008 12:22

Score: 1
Communicatie tussen Larrabee en de gewone cpu wordt verzorgd door Intels driver
Goed artikel en prachtig ontwerp. Ik kijk echt uit naar de Larrabee maar bovenstaande quote maakt me toch een beetje bang. Zal de Larrabee à la SLI alleen op intel chipsets draaien met intel procs? Stel dat het een ontzettend groot succes wordt, dan zal intel iedereen naar een compleet intel toe lokken. Stel dat er weinig animo dan willen ze het op zoveel mogelijk platformen ondersteunen?

Ik ben benieuwd wat ze ervan bakken. Intel Atom was ook een succesvolle pentium-revival dus we zullen zien of die trend aangehouden wordt. Tegenover de Niagara en de Cell zal het ongetwijfeld een knaller worden.

Door arjankoole, donderdag 14 augustus 2008 12:33

Score: 1
ik begrijp je angst wel.

Maar: er was ooit een angst dat 3DFX (toen eigelijk monopolist) te veel macht zou krijgen. Toen kwam nVidia, en daar gingen ze. Uiteindelijk werd 3DFX overgenomen door nVidia, en zo komen we aan SLi in de Geforce series. (mijn goeie oude voodoo 2 kon ook al SLi, en dat was in 1999.)

ik maak me wel zorgen om nvidia trouwens, van de 3 grote partijen is nvidia de enige die niet in het geintegreerde cpu/gpu verhaal zou meekunnen op dit moment. Eventueel zou een aliantie of zelfs overname/fusie met Via voor de hand liggen, maar dat is nog niet gezegt.

Door NitroX infinity, donderdag 14 augustus 2008 12:54

Score: 0
Voodoo 2 = 1998. Overigens beschikte de Voodoo Graphics ook al over SLI en dat was in 1996.

Door DanTheBanjoman, zaterdag 16 augustus 2008 00:10

Score: 0
Los van het feit dat het dezelfde afkorting heeft is het een totaal andere techniek dat in die Voodoo's zat.

Door TeXiCiTy, donderdag 14 augustus 2008 13:00

Score: 2
nVidia en VIA hebben wel heel andere doelen. nVidia wil de snelste zijn, VIA de zuinigste. Niemand die een VIA Nano koopt met een 9800GTX erop... Vandaag.
Als nVidia het echt zo hoog in de bol heeft dat ze met de gpgpu alle CPU taken over willen nemen zou een VIA proc toch genoeg zijn om te booten.

Al met al juichen we met zijn allen verandering toe maar durven we ons niet aan te passen. x86 is niet moeders schoonste maar iedereen blijft plakken en de compatibaliteit is een heilig goedje. Ben ook zeker benieuwd in hoeverre ontwikkelaars apart moeten gaan ontwikkelen voor nVidia Cuda, Ati Fusion, Intel Havok, Intel Larrabee. Intel Only games zit niemand op te wachten, tenzij ze een plek op de consolemarkt hiermee veroveren net zoals de Cell die anders alleen op een stel universiteiten terecht zou zijn gekomen.

Door hollandismad, donderdag 14 augustus 2008 13:31

Score: 1
Ik kan niet wachten om te zien wat dit gaat doen voor real-time raytracing. Als we met z'n allen blijven hangen aan die hardware rasterizers dan wordt dat nooit wat(al is het wel de toekomst), maar larrabee heeft die beperking niet en toch heel veel parallelle rekenkracht. Het is een hele mooie oplossing die de wegen van beide werelden kan bewandelen(op een redelijk tempo) en dus voor een soepele overgang zou moeten kunnen zorgen.

Door SG, vrijdag 15 augustus 2008 07:47

Score: 2
Nou niet veel.
De eerste obstakel is genomen. En dat is ruim voldoende massa parralel computing power. Wat alleen maar zal groeien in het aantal cores.
Maar er is nog geen Raytracing power target platform. ze b eginnen bij nul vs half miljard wat de classieke methode al jaren gebruikt. Dev's staan dus niet te springen om de bestaande methode maar te laten vallen.
Als je vroeg Raytracen serieus wil pushen moet je Raytrace game engine 2 methoden ondersteunen. Raytrace op LArrabee en raytrace op unifiedshaders.

Dan om markt aandeel te winnen moet Larrabee ten eerste 'n DirectX/openGL performance leveren die gelijk waardig of zelfs de huidige methode overtreft.

Zo ook zal praktisch de raytrace methode ook die nextgen GPU ook in raytrace shader performance ook moeten overtreffen.

Omdat nu pas paar detail beken zijn en niet voledig kan men nog niet veel zeggen of wat nauwkeuriger speculeren over wat het aan performance gaat brengen.
Ook ATI en nV nextgen waar het tegen op moet is ook nog onbekend.
Als dit al DX11 + hardware zal zijn. Die SM5.0 shaders zullen ook steeds dichter naar een CPU core gaan.

Raytracen is ook al dedaan op GPU. Die shaders zijn er ook uitermate geschikt voor. En dat ging ook aardig beter dan wat CPU kan.

Dus of het zo'n sucses wordt, geen idee. Maar zeker niet op korte termijn.

Want de dev wereld moet omslaan en die hebben 'n grote codebase en experience met de huidige methode en middleware die dat ook volgt.

Daarnaast heeft raytracing niet voor elke game zoveel zin.

Zoals Quake met heelveel shine balls en mirrors. Dat is geen game.
Die spiegels en shine ball passen niet in de game opzet van quake.
'n level op 'n kermis met zo'n spiegel attractie zou dat logisch zijn.
Maar raytracing voor één map. Of 'n paar spiegel verspreid door de hele game.
Dat kan de huidige rendere methode ook. Misschien minder efficient. Maar dat voldoet.
Water dito. Tenzij de game waterworld heet. Veel games hebben amper water scenes.
Shiny objects cube mapping voldoet en is al ruim believale. Als gamer ga ik geen reflexies controleren in game.
Dus Dev staan er niet zo hard om te springen.

Betere Schaling. Leuk maar waar zal de cross overpoint zitten. Als LArrabee pass asskickt op 2560x1600 hebben ze eigenlijk veloren. De omslag punt bij de massa ligt rond 1024x768.
Als van af daar de betere schaling inzet. Heeft larrabee 'n duidelijk voordeel.
in die resoos moet larrabee de huidige methode overtreffen

Dat stimuleerd de overstap van gamers. En bevorderd target platform groei
En dev's zullen wel volgen als de target groeid en interrerresanter wordt, maar dat gaat 'n stuk langzamer. Game produktie duurt lang zo ook migratie die met die verlate response te maken krijgt.

Door Kailash, donderdag 14 augustus 2008 12:30

Score: 0
Goed en interessant artikel! Ik ben heel benieuwd naar de verdere ontwikkeling, ziet er veelbelovend uit, en ook naar het antwoord van de andere spelers.
Wat zal Sun, IBM, ATI en nVidia hiertegenover gaan stellen?
Een ding is zeker: spannende tijden en de klant vaart er wel bij! :)

Door Lightmanone1984, donderdag 14 augustus 2008 12:41

Score: 1
Wacht ff hoor..

de 9800gtx+ heeft een doorvoersnelheid van 70 GB/s en intel wil dat concureren met maar 17GB/s ?? the hell.. ik denk dat dat niet een beetje HEEL erg ondermaats is?

Door Wouter Tinus, donderdag 14 augustus 2008 13:00

Score: 2
Wat je ziet op dat plaatje is een multisocket serverversie van Larrabee, waarbij 17GB/s de bandbreedte is tussen de sockets onderling. Ieder socket heeft daarnaast zijn eigen geheugencontroller, met ook een x hoeveelheid bandbreedte (25-35GB/s lijkt een goede gok als je ziet waar de gewone CPU's heengaan).

De PCIe-versie van Larrabee krijgt hoogstwaarschijnlijk een aantal GDDR5-geheugencontrollers met een flink sloot bandbreedte, in dezelfde orde als de concurrenten.

[Reactie gewijzigd door Wouter Tinus op donderdag 14 augustus 2008 13:07]

Door CptChaos, donderdag 14 augustus 2008 13:09

Score: 1
Wacht ff hoor..

de 9800gtx+ heeft een doorvoersnelheid van 70 GB/s en intel wil dat concureren met maar 17GB/s ?? the hell.. ik denk dat dat niet een beetje HEEL erg ondermaats is?
Hangt er natuurlijk ook vanaf wat voor soort bewerkingen de Larrabee doet en de 9800GTX+... ;) Bedenk je overigens ook, dat de lanes verschillen, de een heeft X-stappen en de andere Y-stappen. In die stappen kan degene met de langste lane, meerdere bewerkingen doen dan de andere...

Maakt de doorvoersnelheid lager, maar wel meer per uitvoering per lane.
Zie het als een busje of een vrachtwagen over twee verschillende rijstroken op de weg... ;)

Door mrfu, donderdag 14 augustus 2008 12:53

Score: 1
Maar als je dit zou moeten uitleggen aan iemand die er niet zoveel verstand van heeft...
Is het dan een CPU met GPU functionaliteit of een GPU met CPU functionaliteit?
En waarom?

"Omdat het anders wel een GPCPU had geheette" vind ik niet voldoende... :p

Door .oisyn, donderdag 14 augustus 2008 13:17

Score: 2
Het is een CPU met GPU functionaliteit. Die functionaliteit vertaalt zich dan voornamelijk naar een texture-unit om op hardware-niveau textures te filteren, iets waar general purpose moeite mee hebben (texture coordinaten omzetten vertalen naar device coordinaten en geheugenadressen, pixelblokken fetchen waarbij je rekening moet houden met mipmaps en samples die nodig zijn voor anisotropic filtering, en het daadwerkelijk filteren). Voor de rest is het een volledige general purpose CPU met heel veel rekeneenheden.

Overigens gaan hedendaagse GPU's sowieso steeds meer de CPU kant op. Vroeger had je een "fixed function pipeline", waarbij je per pixel niet veel meer kon doen dan een paar textures fetchen en die op een of andere manier combineren. Toen kwamen programmeerbare shaders waarin je hele berekeningen uit kon voeren. En dat ging steeds verder, zodat je bijvoorbeeld ook if-statements en loops kon doen, en later kon je ook nog eens zelf de geometrie genereren op de GPU. Het zal niet lang meer duren voordat de hele pipeline softwarematig geimplementeerd kan worden, en dan zijn het in feite gewoon CPU's :).

[Reactie gewijzigd door .oisyn op donderdag 14 augustus 2008 13:23]

Door Santhem, donderdag 14 augustus 2008 12:54

Score: 0
Het wil niet zeggen dat die doorvoersnelheid voor de volle 70GB/s word gebruikt. Als 17GB/s genoeg is om snel genoeg door te voeren wat hij door moet voeren, lijkt me dat een perfecte snelheid.

Door Piraatje, donderdag 14 augustus 2008 13:14

Score: 1
Ik vind dit een zeer slimme richting die Intel ingegaan is. Dit is dan misschien niet de ideale methode voor OpenGL en DirectX toepassingen, maar voor ray tracing (ooit toch wel de toekomst van 3D applicaties) en natuurkundige berekeningen is het waarschijnlijk zeer goed geschikt. Temeer omdat het zo goed schaalbaar is.

*gaat aandelen Intel op zijn verlanglijstje zetten* ;)

[Reactie gewijzigd door Piraatje op donderdag 14 augustus 2008 13:14]

«  1  2  »

Op dit item kan niet meer gereageerd worden.

VNU Media logo Hosted by True

© 1998 - 2012 Tweakers.net B.V. - Alle rechten voorbehouden - Contact - Jouw privacy - Algemene Voorwaarden

Uitgever van:

Website van het jaar 2011