Door Wouter Tinus

Larrabee: op het kruispunt van gpu en cpu

14-08-2008 • 11:40

62

Multipage-opmaak

Introductie

Lange tijd hebben videokaarten en processors vredig naast elkaar bestaan, zonder dat de een zich zorgen hoefde te maken over concurrentie van de ander. De laatste jaren hebben onvermijdelijke technische ontwikkelingen - versterkt door doelbewuste acties van fabrikanten - de mogelijkheden van de twee dichter bij elkaar gebracht. Hiermee is een zeer interessante strijd ontstaan. De inzet: wiens chips gaan de volgende generatie van rekenintensieve applicaties draaien.

Intel heeft eerder deze maand een hoop details vrijgegeven over Larrabee, het eerste concrete antwoord van het bedrijf op de opkomst van gpgpu. In dit artikel gaan we bekijken wat er tot nu toe bekend is gemaakt over de techniek achter Larrabee, wat we al weten over de prestaties en wat voor impact het product mogelijk gaat hebben. Om te beginnen zullen we echter kijken hoe het slagveld er op dit moment bij ligt.

*De stand van zaken

Nvidia De drie belangrijkste spelers in deze strijd hebben ieder een andere aanpak. Nvidia ziet brood in general purpose-code op een grafische chip. De brute rekenkracht die in het leven is geroepen voor spellen moet volgens deze fabrikant op termijn zo eenvoudig aangesproken kunnen worden dat de gewone cpu een ondergeschikte rol gaat spelen.

AMD kiest voor de agnostische aanpak: het maakt hen niet veel uit of code uiteindelijk op een cpu of op een gpu komt te draaien, want ze hebben ondertussen beide in huis. Voor deze verzekering is wel de hoofdprijs betaald: twee jaar geleden heeft het bedrijf ruim vijf miljard dollar opgehoest voor ATI, waardoor het nu nog diep in de schulden zit. AMD wedt dus op twee paarden, maar gezien het feit dat de processors de laatste tijd een stuk minder goed lopen is het niet verwonderlijk dat AMD de laatste tijd vooral de gpu naar voren schuift.

Hoewel Intel een prima processor in huis heeft, zijn de grafische oplossingen van het bedrijf tot nu toe niet veel meer dan functioneel te noemen. Plotseling geconfronteerd met een markt die geen trek meer had in nog warmere processors heeft Intel ingezet op multicores, maar terwijl ontwikkelaars zich aanpassen aan 2, 4 of misschien net 8 threads, lonken ATI en Nvidia met honderden parallelle eenheden.

Om een idee te geven van het verschil: op papier laat een Radeon 4870 of Geforce GTX 280 een topmodel Nehalem met een factor 10 in het stof bijten. We hebben het dan over ruwe 32bits flops. In de praktijk is die kracht nog moeilijk aan te spreken. Software moet behoorlijk door de mangel gehaald worden om op een gpu te kunnen werken en om goede prestaties te krijgen is een flinke dosis kennis nodig over de interne werking van het apparaat. Met iedere generatie wordt de hardware echter flexibeler en worden er ook betere ontwikkeltools beschikbaar gesteld, waardoor de bedreiging reëel is.

Club3D Radeon HD 4870

* Larrabee

Intels antwoord op deze ontwikkelingen is Larrabee, een ver schaalbare multicorechip die - onder meer - dienst kan doen als grafische processor. Intel is niet nieuw in de grafische wereld. Het is zelfs al jaren marktleider, omdat het voor een meerprijs van slechts enkele dollars een geïntegreerde oplossing levert die weinig stroom verbruikt en voor veel mensen gewoon goed genoeg is. Met Larrabee mikt Intel echter hoger: ze willen op termijn zelfs de meest veeleisende gamers plezieren.

Het meest fundamentele verschil tussen Larrabee en andere grafische kaarten is dat Intels chip gebaseerd is op een x86-core. De chip zal door spellen gewoon via Directx en Opengl aan te spreken zijn, maar terwijl ontwikkelaars zich in bochten wringen om een ATI- of Nvidia-gpu ook op een andere manier te gebruiken, zal dat voor Larrabee op bijna dezelfde manier gaan als bij een gewone processor.

Dat comfort zou ontwikkelaars moeten overtuigen om te stoppen met gpgpu en in plaats daarvan bij x86 te blijven. Pat Gelsinger, een van Intels topmanagers, denkt dat gpgpu uiteindelijk niet meer zal worden dan 'een interessante voetnoot in de geschiedenis van computers' . Zijn bedrijf heeft daar uiteraard behoorlijk wat belang bij.

Pimp my Pentium

Om Larrabee vanuit technisch oogpunt te bestuderen beginnen we bij de core. Intel zegt dat deze is gebaseerd op de originele Pentium. Dat mag tot op zekere hoogte dan wel waar zijn, maar van de andere kant is het ook misleidend. Er zijn behoorlijk wat toeters en bellen toegevoegd die zelfs in Nehalem ontbreken.

Pentium 166MHz with MMX

Larrabee is net als de Pentium een in-order ontwerp dat maximaal twee instructies tegelijk kan uitvoeren. Maar hetzelfde geldt voor Atom, die door Intel nooit vergeleken is met een architectuur uit 1993. Gespeculeerd wordt daarom dat Larrabee net als de Pentium een korte pipeline heeft. De Pentium had namelijk maar 5 stappen, terwijl Atom er 16 heeft. Hoe lang de pipeline van Larrabee precies is, wil Intel op dit moment echter nog niet kwijt.

Hoe dan ook is de core flink op de schop genomen. De Pentium is nog nooit kleiner gebakken dan 0,25µm en moest dus maar liefst vijf generaties gekrompen worden om de 45nm te bereiken. Daarnaast is ondersteuning voor 64bit-instructies en hyperthreading met vier threads toegevoegd . Voeg daar specifieke nieuwe eenheden en instructies aan toe voor grafische toepassingen en het ontwerp is van dichterbij nauwelijks meer herkenbaar.

Het belangrijkste punt is echter dat het een kleine en hele simpele core is. Tijdens het ontwerp heeft men becijferd dat er binnen het transistorbudget en het tdp van een Core 2 Duo maar liefst tien Larrabee-achtige cores passen, die samen veertig keer zoveel floating point-werk per kloktik kunnen verzetten.

* x86-uitbreidingen

Zoals gezegd is de Larrabee-core eigenlijk geen familie meer van de Pentium te noemen. Een van de meest in het oog springende toevoegingen is een 512bit brede vectoreenheid die op 16 waarden tegelijk kan kauwen. Dat is vier keer zoveel als een normale core van Intel of AMD op dit moment aan kan.

De vectoreenheid heeft ook een aantal slimme features die niet terug te vinden zijn in gewone x86-chips. Zo is het mogelijk om delen van de uitvoer te maskeren. Daarmee kan de hardware bijvoorbeeld bij een if-else constructie beide mogelijke paden tegelijk bewandelen, om halverwege te besluiten welke aan het einde zal worden doorgelaten. Samen met wat extra hardware voor het converteren en herschikken van data maakt dit de vectoreenheid een stuk waardevoller dan een standaard sse-implementatie.

Larrabee architectuur
Links: de hele Larrabee-core | Rechts: ingezoomd op de vectoreenheid

Een tweede grote verandering is het toevoegen van instructies met drie parameters. De belangrijkste operatie die hierdoor mogelijk wordt is fmac. Zoals de naam al zegt is dat een instructie om een vermenigvuldiging en een optelling in een keer uit te voeren. Dit is een populaire instructie voor grafisch rekenwerk die het aantal gigaflops effectief kan verdubbelen. De fmac is wel aanwezig in Itanium en de Power-architectuur van IBM, maar binnen de x86-wereld heeft Larrabee met deze toevoeging de primeur.

Nog een innovatie die uniek is voor een x86-chip is de implementatie van gather en scatter. Deze instructies maken het makkelijk om te werken met vectoren van waarden die niet vooraf netjes naast elkaar in het geheugen zijn gezet. Een programmeur die een vector wil vullen kan hiermee een lijst van 16 adressen samenstellen en met een instructie alle data bij elkaar sprokkelen. Op dezelfde manier kan hij met een instructie alle delen van een vector laten wegschrijven naar verschillende adressen.

Gather scatter illustratie

De Larrabee-core heeft 64KB L1-cache en 256KB L2-cache tot zijn beschikking, wat voor het eerst beheersbaar is gemaakt vanuit software. Het is bijvoorbeeld mogelijk om de prefetchers aan te sturen, data rechtstreeks naar het gewenste niveau te laden én om het er weer uit te schoppen. Wanneer de programmeur weet dat hij eenmalig een groot blok moet doorlopen, zoals een texture, kan hij er voor zorgen dat deze niet in de cache wordt opgeslagen, zodat de overige gegevens die later nog wel nodig zijn, snel toegankelijk blijven.

Belangrijk om te weten is dat Larrabee garandeert dat de caches altijd synchroon zijn. Mensen die gewend zijn om met x86 te werken zullen niets anders verwachten, maar bij een Geforce of een Cell kan de hardware dit niet afdwingen, waarmee het als oefening aan de programmeur wordt overgelaten om ervoor te zorgen dat er niets mis gaat tijdens de interactie tussen verschillende threads.

Tot slot zijn er nog enkele specifieke instructies toegevoegd, zoals bit count en bit scan, die specifieke delen van het renderen enkele procenten sneller maken. Ondertussen is hopelijk wel duidelijk geworden dat Larrabee mijlenver van de Pentium staat, ondanks de overeenkomsten op hoog niveau.

Larrabee

Intel heeft nog geen concrete details bekendgemaakt over specifieke implementaties van Larrabee, maar duidelijk is wel dat chips met 8 tot en met 64 cores tot de mogelijkheden behoren. Men zal op basis van de yields en prestaties van de samples een afweging moeten maken over concrete producten voor verschillende doelgroepen, maar daar is het op dit moment mogelijk nog te vroeg voor. Intel heeft het vooralsnog alleen maar over simulaties gehad.

Binnen een chip worden tot 16 cores en andere onderdelen aan elkaar geknoopt door een 1024 bit brede ringbaan, waarbij de helft linksom gaat en de andere helft rechtsom. Naast de cores zelf kunnen ook andere zaken op de bus worden aangesloten, zoals gddr-geheugencontrollers, een pci-express-interface, Quickpath of eenheden met een bijzondere functie, zoals een video-encoder. Versies van Larrabee met meer dan 16 cores zullen meerdere ringen gebruiken die elkaar kruisen aan de randen.

Intel Larrabee-architectuur

Een van de weinige grafische functies die de Larrabee-core uitbesteedt aan een stuk vaste hardware is het filteren van textures. Intel heeft berekend dat dit afhankelijk van de compressie 12 tot 40 keer trager zou lopen op een x86-core, waardoor de keuze voor een vast stuk hardware snel gemaakt was.

Vrijwel alle andere stappen van het renderen houdt Intel echter op softwareniveau. Dit gaat tot op zekere hoogte ten koste van de efficiëntie, maar het heeft ook zijn voordelen. Zo kan er geen sprake zijn van een specifieke bottleneck in de chip: hij is snel genoeg of niet, maar het zal niet voorkomen dat een traag onderdeel de rest tegenhoudt.

Verder geeft een software-implementatie veel flexibiliteit. Er is een redelijk goede kans dat Larrabee alleen een nieuwe driver nodig heeft om bijvoorbeeld Directx 11 of 12 aan te kunnen. Dit terwijl een gpu vaak blijft steken op een oudere versie omdat er net een feature aangepast moet worden die hard in de hardware zit gebakken.

Tot slot draagt Intel aan dat eenheden met vaste functies een blok aan het been van de schaalbaarheid kunnen vormen. De fabrikant heeft overwogen om ook het rasteren efficiënter te maken door het in hardware te implementeren, maar de synchronisatie en coördinatie die daarbij komt kijken zouden het lastig maken om naar grote aantallen cores te schalen. Vandaar dat ze wat inefficiëntie in deze stap voor lief nemen en dit deels compenseren met nieuwe instructies.

F.E.A.R. rendertijd uitgesplitst
De hoeveelheid rekenkracht die nodig is voor verschillende stappen van het renderen verschilt van frame tot frame. Tussen verschillende spellen zijn de verschillen nog groter. Intel redeneert dat flexibele hardware die aan het hele proces kan meewerken beter is dan een vastgebakken stuk dat een onderdeel afhandelt, zelfs wanneer laatstgenoemde tot op zekere hoogte efficiënter werkt.

Software en schaalbaarheid

Omdat Larrabee bijzonder weinig hardware met een vaste functie heeft, zijn de Directx- en Opengl-renderpipelines bijna volledig in de software geïmplementeerd. Er is gekozen voor een tile-based aanpak waarbij een frame opgedeeld wordt in kleinere blokken. De grootte daarvan is afhankelijk van de complexiteit, maar zou tussen de 32x32 en 128x128 pixels liggen. De begrenzende factor is hier de grootte van de L2-cache, omdat ieder blok uiteindelijk aan één core wordt toegewezen, die het efficiëntst werkt vanuit zijn eigen snelle geheugen.

Een nadeel van de tile-based aanpak is dat polygonen die twee of meer blokken raken gekopieerd moeten worden en dus meerdere malen in de cache staan, maar dat zou maar ongeveer 5 procent overhead opleveren. De bandbreedtebesparing die bereikt wordt doordat niet iedere core zich met de hele scène bezig hoeft te houden zou daarentegen te allen tijde minstens 30 procent zijn en oplopen tot ver boven de 50 procent.

Larrabee: tile-based vs. standaard bandbreedte

Ook andere problemen die ouderwetse tile-based rendersystemen hadden, meent Intel met zijn software-implementatie te hebben opgelost. Om met effecten als reflecties en schaduwen om te gaan construeert het programma een afhankelijksheidsboom tussen verschillende tiles, zodat het mogelijk is om tijdens het tekenen van een frame alvast te beginnen met het berekenen van de schaduwen voor de volgende.

* Schaalbaarheid

Voor zover bekend zijn er nog geen gegevens bekendgemaakt over de kloksnelheid en het aantal cores van verschillende Larrabee-producten, waardoor het erg moeilijk is om op dit moment al over de prestaties te spreken. Wel is Intel zo vriendelijk geweest om te simuleren in hoeverre het ontwerp schaalbaar is.

Het bedrijf heeft uit de spellen Half-Life 2: Episode 2, Fear en Gears of War ieder 25 frames geplukt van verschillende scènes. In alle gevallen was de schermresolutie 1600 bij 1200 en de eerste twee spellen draaiden met 4xAA. Door alle Directx-commando's op een systeem met een gewone videokaart te onderscheppen en dezelfde serie later op een Larrabee-simulator af te schieten heeft men onderzocht hoe de chip presteert met verschillende aantallen cores.

Uit deze simulatie is gebleken dat de chip in ieder geval van 8 tot 48 cores met 90 tot 93 procent bijna perfect schaalt. Dat wil zeggen dat een versie met 32 cores daadwerkelijk bijna twee keer zo snel is als een versie met 16 cores, mits ook het aantal texture-eenheden en de geheugenbandbreedte meegroeien. Door de code verder te tweaken werd in een van de spellen zelfs 98 procent bereikt.

Uitgaande van een kloksnelheid van 1GHz, heeft Intel berekend dat deze drie spellen met 25 cores steeds minimaal 60 frames per seconde moeten halen. Wat dat betekent voor de gemiddelde framerate bij verschillende kloksnelheden en aantallen cores laten we als oefening voor de lezer over.

Larrabee: aantal 1GHz-cores nodig voor 60 fps

* Andere applicaties

Belangrijk om in het achterhoofd te houden is dat Intels Directx-renderer maar een van de mogelijke applicaties is die op een Larrabee-processor kunnen draaien. Het doel is dat straks iedereen zijn eigen 'Larrabee Native Application' kan schrijven, wat actief wordt ondersteund met een optimaliserende compiler en voor Larrabee geoptimaliseerde blokken in de Math Kernel Library, een gereedschapskist voor ontwikkelaars.

De meeste x86-software zou zonder aanpassingen op Larrabee kunnen draaien, maar het is wel nodig om gebruik te maken van de (vector)extensies en tientallen threads om het maximale er uit te slepen. Communicatie tussen Larrabee en de gewone cpu wordt verzorgd door Intels driver, die zowel synchroon als asychroon data kan versturen en zelfs toegang tot bestanden op de harde schijf kan regelen.

Om aan te tonen dat Larrabee veel meer kan dan alleen graphics heeft Intel nu al een paar andere toepassingen voor de chip ontwikkeld, waaronder de simulatie van verschillende natuurkundige effecten, ray tracing en populaire supercomputercodes. Volgens het bedrijf kan Larrabee veel beter omgaan met complexe datastructuren dan een gpu, wat het aanpassen van bestaande algoritmes eenvoudiger maakt.

Larrabee: raytracing prestaties
Raytracing op Larrabee

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.

Reacties (62)

62
58
31
13
0
1
Wijzig sortering
Er kunnen dus flink wat cores op. Mag ook wel. Misschien worden in de toekomst zelfs systemen met meerdere larrabee's gemaakt, hoewel, als je met 64 cores op één chip uit de voeten kan, en die ook nog krachtig kan maken, is dat nog geen eens nodig. Zeg maar sterk overbodig.
Maar zo'n grote hoeveelheid cores mag ook wel hoor. Tegenwoordig (ik reken nu de geluidskaart en mogelijk aanwezige PPU niet mee, want dat is hier niet van belang) heeft elk systeem twee processorcores (1x CPU + 1x GPU, hoewel dit ook onboard kan zijn, maar dat laatste is dan nog steeds een processor). Een zichzelf respecterend systeem heeft er wel 3 (2CPU cores + 1 GPU). Dan heb je ook nog de echte gebruiker die er 3 tot 6 heeft (2-4 krachtige CPU cores + 2 krachtige GPU cores). En de echte die-hard heeft er wel 14 (met 2*4 of 1*8 zware C-jongens en 3*2 GPU cores). En er bestaan ook nog 8-core CPU's.
Natuurlijk kunnen er nog genoeg andere combinaties, maar dat wordt dan lastig om zo neer te typen.

Ik zie hier verder wel wat in. Grafische kracht en CPU-kracht zijn veel makkelijker op elkaar af te stellen. Een bottleneck gaat waarschijnlijk erg worden vermoeilijkt in de Larrabee.
Je hebt niet snel een GPU die tien keer zo krachtig is als je CPU, of andersom.
Ik zie wel iets in deze oplossing, hoewel voor de echte gamers onder ons er misschien toch nog wel flink wat geheugen bij mag. Op een beetje hoge resolutie gamen met 8MB L2-cache...
Heb ik geen hoge pet van op. Tegenwoordig worden niet voor niets grafische kaarten uitgerust met 256-1024mb geheugen. Ik game liever op een leuke resolutie.
Waarom is de bovenstaande reactie +2 "must-read"?
Maar zo'n grote hoeveelheid cores mag ook wel hoor. Tegenwoordig (ik reken nu de geluidskaart en mogelijk aanwezige PPU niet mee, want dat is hier niet van belang) heeft elk systeem twee processorcores
Wat heeft hoeveelheden cores nu met rekenkracht of wat dan ook te maken? Tilera maakt al jaren systemen met 64 "cores", maar dat zegt niets over hoe goed je daar word, office of games mee kan draaien. NVIDIA wil de consumenten zelfs graag laten geloven dat er op hun kaarten maar liefst 240 'cores' zitten (wat onzin is, het zijn er maar 30), maar dat is ook op geen enkele manier vergelijkbaar met een CPU of zelfs met Larrabee.
Grafische kracht en CPU-kracht zijn veel makkelijker op elkaar af te stellen. Een bottleneck gaat waarschijnlijk erg worden vermoeilijkt in de Larrabee.
Je hebt niet snel een GPU die tien keer zo krachtig is als je CPU, of andersom.
Waarom niet? Larrabee GPUs zijn net als nu PCI-E insteekkaarten, dus als je die wilt combineren met een VIA Nano is dat geen enkel probleem. Larrabee kan echt niet zomaar even een deel van je gewone processorwerk van je overnemen hoor, het is voornamelijk een GPU, alleen met een CPU-achtig ontwerp.
Op een beetje hoge resolutie gamen met 8MB L2-cache...
Euh... weet je wat cache is? Het is een kleine hoeveelheid geheugen die op de processor zit zodat niet elke keer de langzame weg naar het systeemgeheugen gekozen hoeft te worden. Je normale desktopprocessor heeft ook een paar MB L2 cache, en NVIDIA en ATI hebben ook cache in hun GPUs zitten.
Larrabee krijgt gewoon een flinke hoeveelheid GDDR geheugen, net als alle andere GPUs van dit moment.
8MB L2 per core, dus in het geval van 64cores zit je al snel op 512MB. Hoewel dat wel een beetje krap is vergeleken met de concurrent (als je aanhoud dat Larrabee pas in 2010 komt that is!)

Maar 1920*1080*32bit = 8MB en ik voorzie snel textures van die maat. Dan aangemonen dat er flink wat verschillende textures in 1 scene/frame zitten loop je toch (zover ik het zie) redelijk snel tegen 512MB aan in de toekomst.
Maar dan gebruik je dus toch nog alle 512MB alleen voor alle textures. Voor het central processing zelf blijft er niks over.
Volgens het artikel heeft één zo'n core trouwens 64KB L1-cache en 256KB L2-cache. Wat mij voor gaming helemaal angstaanjgend lijkt.
Waar het 4-32 GB uit het plaatje over gaat weet ik niet zeker, maar aangezien het zo relatief veel is denk ik dat het om RAM-geheugen gaat (hoewel het vreemd is dat er geen 1 of 2 GB of zelfs nog minder staat, maar misschien verwacht intel dat in 2010 nieuwe pc's geen 2GB meer zullen hebben). Dat is voor gaming ook angstaanjagend, want dan krijg je dus shared memory. Dat is bekend als slecht.
Zoals gemeld, deze komt er hoogstwaarschijnlijk ook als insteekkaart met snel GDDR5 geheugen, non shared.
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.
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.
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 25 juli 2024 05:59]

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.
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.
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)
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?
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 25 juli 2024 05:59]

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... ;)
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.
Pardon, de huidige top kaart heeft 2,4TFlops... namelijk de HD4870X2. Of telt het niet mee omdat ie 2 cores heeft? :/

[Reactie gewijzigd door Verwijderd op 25 juli 2024 05:59]

RV770 geeft al 1,2 terraflop. dat is heel dicht bij 1,5.

Maar. Die 1,5 moet ook veel andere taken doen. behalve texture filtering. Maar de rasterizer rops etc is bijna allemaal ook software. Dus die Larrabee kan flink inboeten en dat voor flexibliteit.

Als je de DIE van GT200 en rV770 bekijkt zie je dat shader blokken ook andere unit herbergen en dus maar minder dan de helft dus puur shaders zijn.
Die rest is fixed function wat dat doet kan het veel beter. Daar heb je dus meer X86 cores voor nodig om dat te halen. je bent dan wel flexibler maar met 'n performance cost.

Larrabee zal grotendeels uit X86 cores bestaan. dus maar 'n deel zal het opnemen tegen de GPU shaders.

Maar RV770 en GT200 zal niet zijn competitie worden eerder RV870 GT300 of iets DX11.
1,5 is dus magertjes want mogelijk dat RV870 al daar overheen gaat en de fixfunction units doen ook hun number crunching erbij.

Ik wacht eerst af. kan namelijk ook 'n fiasco worden.

De eerste mijlpaal die iNTel moet halen is competatieve DirectX performance.

Hiervoor zijn ze afhankelijk van hun Team die aan de software side werken.
De DirectX software rendere library en uiteraard goede drivers.
iNtel GFX driver team moet dus groter.

wat iNTel wel mee heeft is de nieuwste dieschrink tot hun beschikking.

Wordt iig hele interresante tijden de komende 2 a 3 jaren.
Een kaart is geen gpu ;). Als je een Radeon X2 wil meetellen dan moet je ook een "Larrabee X2" overwegen, kom je op dezelfde percentages uit.

[Reactie gewijzigd door Wouter Tinus op 25 juli 2024 05:59]

Och, dan moeten we spreken over een "Larrabee x24" dus ik vind zijn opmerking terecht
oeps dubbele reply (moest op een andere post :S )

[Reactie gewijzigd door Powrskin op 25 juli 2024 05:59]

+ ook al reken je 1 core dan klopt die 25/50% sneller als huidige Gpu's nog niet.

zal ik het andersom zeggen :P
1 Larrabee core doet 0.0625 teraflop tegenover 1.2teraflops van de HD4870 (1 staat tot 19 zegmaar).
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
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 25 juli 2024 05:59]

Het prachtige is dat intel zoveel belang hecht aan software-programmatie. Dit betekent dat linux developers ook helemaal niet meer hoeven te klagen: schrijf je eigen OpenGL-implementatie, zagers!

Het gekke is dat de Cell-processor nooit op een aparte kaart is uitgekomen. Die zou ook heel makkelijk een videokaart kunnen vervangen. Hell, ELKE processor kan makkelijk 3d-kaart spelen als je een stukje framebuffer reserveert en daar een RGB DAC aan koppelt... Hoe zou de niagara presteren als videokaart?
Het gekke is dat de Cell-processor nooit op een aparte kaart is uitgekomen.
Jawel hoor, kost alleen grof geld: nieuws: Mercury introduceert PCIe-kaart met Cell-processor
OpenGL is al Cross-platform...
Gaat waarschijnlijk over de bagger-openGL drivers van nVidea en ATi, die geen specs willen(/wilden) vrijgeven over hoe hun kaart werkt. OpenGL is idd Cross-Platform, maar zonder 3d-drivers kom je nergens ;)
Waar ik benieuwd naar ben is zijn de opties om deze Larrabee als General Purpose CPU te gebruiken. Het is tenslotte een CPU met de x86 instructieset dus zou deze ook in staat moeten zijn om gewoon Windows te draaien en de hele reutemeteut, of zie ik dat verkeerd?

In dat geval zou de Larrabee ook kunnen volstaan als CPU/GPU in een computer lijkt mij. Maar het geeft ook voordelen bij berekeningen. De ene berekening kan vlot op de huidige manier worden behandeld (zoals nu normaal is bij x86), maar physics zouden een stuk sneller kunnen worden afgehandeld op de manier zoals de videokaarten hier nu mee omgaan (zie oa NVIDIA Cuda).

AMD gaat met Fusion natuurlijk bovenstaande wel waarmaken. Maar Fusion heeft, voor zover ik het zie, het nadeel dat het toch 2 aparte blokken blijven. Bij veel Physics berekeningen zou de Larrabee al zijn kracht kunnen benutten, de Fusion zou alleen de GPU aan het werk zetten terwijl de CPU zelf uit zijn neus mag vreten.

Dit gaat in ieder geval zeker de wereld van onze computers veranderen. Aan de ene kant blijft het "gewoon" x86, aan de andere kant is het eigenlijk iets totaal nieuws in mijn ogen.
Het zijn kleine mini corretjes. Niet elke PC probleem is zo geweldig op te delen in multiple threads. Zoiets als Renderen Physics en AI is dat wel.
Maar vele andere taken wat 'n CPU doet niet.
Dus je heb dan ook regelmatig single thread crunching power nodig.
En dat bieden die zware cores van tegenwoordig. De een zal de ander dus niet vervangen tenzij men die efficentie overboard gooid. Omdat de minder ook redelijk voldoet. Maar zo ve ris het nog niet.
Denk eerder dat men de big en smal samen op m'n die zetten.

Dus quad met 32 larrabee
Dat zou kunnen inderdaad. Feit blijft wel dat deze Larrabee meer optie sheeft om uitkomsten te voorspellen. Mogelijk maakt dat de Larrabee toch sneller dan hij doet vermoeden voor applicaties die niet over heel veel cores kunnen worden verdeeld.
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.
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.
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.
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.
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.
Voodoo 2 = 1998. Overigens beschikte de Voodoo Graphics ook al over SLI en dat was in 1996.
Los van het feit dat het dezelfde afkorting heeft is het een totaal andere techniek dat in die Voodoo's zat.
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?
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 25 juli 2024 05:59]

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 25 juli 2024 05:59]

Op dit item kan niet meer gereageerd worden.