PCStats gaat diepgaand in op de XGI Volari

In mei konden we lezen dat SiS stopte met het ontwerpen van chips voor grafische kaarten. Toch was dit niet het einde van de Xabre GPU, want de hele afdeling ging zelfstandig verder onder de naam Xabre Graphics Incorperated. Of dit een goede zet voor SiS was, is nog niet echt duidelijk, wel is duidelijk dat XGI een grote speler wilt worden. Daarvoor zullen ze echter wel de concurrentie aangaan met de huidige marktleiders, ATi en nVidia. Het was dan ook niet verwonderlijk dat XGI in september een nieuwe serie van GPU's aankondigden met de naam Volari die op papier snel genoeg zouden moeten zijn om met ATi en nVidia te concurreren.

Volari V3
PCStats heeft ondertussen wat meer informatie weten te bemachtigen over de architectuur van de Volari. De GPU zal in vijf verschillende smaken verschijnen. Als instapmodel is er de Volari V3 die bedoeld is voor de DirectX 8.1 API. Deze GPU doet zijn werk op 300MHz, is uitgerust met twee texture-units en kan 128MB aan DDR300-geheugen aansturen via een 128bits brede bus.

Volarie V5 en V8
Voor de DirectX 9.0-markt komt XGI met de Volari V5 en V8. Het verschil tussen beide GPU's zit hem in het aantal pixel- en shader pipelines waarmee ze zijn uitgerust. De V5 heeft er respectievelijk vier en twee, terwijl de V8 er acht en vier heeft. Elke pixel pipeline is uitgerust met twee texture units en daarnaast hebben beide GPU's ook nog eens twee vertex shaders. Van beide GPU's is er ook een Ultra-versie beschikbaar die op een hogere kloksnelheid werkt en ook met sneller geheugen is uitgerust. De geheugeninterface is 256bits breed en kan overweg met zowel DDR- als DDR2-geheugen.

BitFluent
Om echter met bijvoorbeeld de nVidia GeForce FX 5900 Ultra en de ATi Radeon 9800 Pro te concurreren heeft XGI een technologie in hun Volari V5 en V8 ingebouwd die het mogelijk maakt om twee GPU's samen te laten werken, vergelijkbaar met de SLI-technologie van 3dfx. De naam van deze technologie is BitFluent. In plaats van beide GPU's tegelijkertijd dezelfde frame te laten renderen, heeft XGI ervoor gekozen om het eerst volgende frame door de host-GPU te laten renderen en het daarop volgende frame door de slave-GPU te laten renderen. De laatste is hiervoor doormiddel van de BitFluent-bridge op de host-GPU is aangesloten. Hierdoor kunnen beide GPU's met hun eigen geheugen worden uitgerust en zouden ze elkaar niet in de weg kunnen zitten, waardoor de snelheid in theorie verdubbelt.

BroadBahn
Om ervoor te zorgen dat de Volari GPU niet staat te wachten op gegevens uit het geheugen, is hij uitgerust met een speciale geheugeninterface die de naam BroadBahn heeft meegekregen. BroadBahn maakt gebruik van compressie om meer gegevens tussen de GPU en het geheugen te kunnen transporteren. Daarnaast is het geheugen onderverdeeld in vier verschillende banken die ieder hun eigen controller hebben. Hierdoor kan er vanuit of naar verschillende plaatsen in het geheugen tegelijkertijd data worden opgehaald of weggeschreven.

CipherVideo en ColorAmp
Een snelle videochip is een ding, maar het oog wil natuurlijk ook wat. Dat dacht XGI ook en heeft daarvoor twee verschillende technieken ontwikkeld: CipherVideo en ColorAmp. ChipherVideo zorgt ervoor dat videobeelden die van buiten de chip komen een speciale behandeling krijgen waardoor ze er beter uit zouden moeten zien. Zo wordt onder andere het interlaced video-in signaal omgezet in een niet-interlaced signaal. ColorAmp zorgt ervoor dat bepaalde kleuren als het ware versterkt worden waardoor 3d-beelden helderder zijn en 2d-beeld iets meer verzadigd. Uiteraard is de mate en het soort van beeld dat door ColorAmp wordt bewerkt in te stellen door de gebruiker.

Conclusie
Het lijkt erop dat XGI hard op weg is om een geduchte concurrent te worden van ATi en nVidia. Hiervoor zal XGI echter wel een naam moeten opbouwen die ze nu nog niet hebben. Als de kaarten echter presteren zoals XGI beweert met hun benchmarks, dan zou het hun kunnen lukken. Zeer zeker als de support goed is en de prijs laag.

Reacties (47)

[.oisyn]

In plaats van beide GPU's tegelijkertijd dezelfde frame te laten renderen, heeft XGI ervoor gekozen om het eerst volgende frame door de host-GPU te laten renderen en het daarop volgende frame door de slave-GPU te laten renderen. De laatste is hiervoor doormiddel van de BitFluent-bridge op de host-GPU is aangesloten. Hierdoor kunnen beide GPU's met hun eigen geheugen worden uitgerust en zouden ze elkaar niet in de weg kunnen zitten, waardoor de snelheid in theorie verdubbelt.

Ja, dat heeft ook zo lekker veel nut. Alle data en commando's worden gestreamed naar de videokaart gestuurd. Op een gegeven moment is de applicatie met z'n scene klaar, en geeft ie het commando om 'm te tonen op het scherm. De videokaart is nu nog aan het tekenen, en voordat de app verder kan met de volgende frame moet er gewacht worden tot de huidige frame af is. Goed, in deze heeft die 2e GPU dus voordeel, omdat er gelijk met de volgende frame verder kan worden gegaan, maar deze overlap is niet echt supergroot. Vooral ook omdat er tegenwoordig veel gebruik wordt gemaakt van effectien die achteraf nog eens over de framebuffer worden gegooid, zoals (depth/motion) blur, high dynamic range belichting, etc. Dit creeert dus een dependency op de framebuffer, en kan er gewoon niet verder worden gegaan tot ie af is.

Daar komt nog eens bij dat soms ook het resultaat van de vorige frame ook welens wordt gebruikt, waardoor die 2e GPU dus altijd uit z'n neus zit te vreten, omdat die andere nog niet klaar is.

Het is imho echt een vette waste of processing power, en ze hadden hun resources mijn inziens beter kunnen gebruiken om dingen als scanline interleaving oid te doen, waar je gewoon wel echt bijna de volle 100% snelheidswinst mee haalt.

Het zou natuurlijk wel mooi zijn als de app zelf de GPU's onafhankelijk van elkaar kan benaderen, zodat ie zelf de verdeling kan bepalen. Maar dat werkt natuurlijk niet voor al bestaande applicaties, waardoor ze daarbij altijd langzamer zullen zijn dan ATI en nVidia

[Countess]

wat hebben die framebuffers er mee te maken?
die 2de GPU moet toch ook die effecten doen en zal daarom (ongeveer) even lang over zijn frame doen als de eerste GPU. waardoor ze achter elkaar kunnen worden afgevuurt.

de resultaten van de vorige frame heeft hij (meestal) pas nodig als hij klaar is met zijn frame, maar nog niet met de framebuffer effecten, waardoor die vorige frame all lang klaar is, en dus meteen gebruikt kan worden.
en de eerste GPU kan al beginnen aan het maken van de volgende frame omdat hij het frame van de 2de GPU pas nodig heeft als hij de buffer effecten will toepassen, bijna op het einde van het process dus.

edit : damn ik hoop dat dat een beetje te lezen valt.

het nadeel van scanline interleaving is dat polygonen over meerdere lijnen vallen, en de GPU's dus vaak de zelfde polygoon zitten uit te rekenen, wat dus dood zonden is.
(dit gold overigens niet voor de voodoo omdat de CPU daar het grootste deel van het polygonen maken deed, en de vidkaart er allen frames van maakte, do voodoo5 was dus puur fillrate, maar er wel heel goed in )

[.oisyn]

Beetje laat, maar goed

Je begrijpt denk ik niet helemaal wat ik bedoel. Zoals het in het artikel staat wisselen de GPU's elkaar af. De ene GPU doet de ene frame, en de andere GPU doet de andere. Maar met de 2e frame kan pas worden begonnen nadat de commando's van de eerste zijn gegeven. En aangezien juist tegenwoordig veel post-render effects worden toegepast zijn die commando's afhankelijk van de vorigen. Het is dan ook wachten totdat die vorige commando's zijn uitgevoerd voordat de volgende worden geaccepteerd. Met als resultaat dat er een erg slechte overlap is tussen de 2 GPU's, en dat is gewoon zonde.

Wat scanline interleaving betreft: ik weet hiet in hoeverre je verstand van zake hebt mbt 3d rendering, maar wellicht weet je het renderen van een polygoon (triangle) als volgt gebeurt:
- de 3 vertices van de triangle worden getransformeerd
- clipping tegen het view frustum en evt. nog andere user clip planes
- backface en viewport culling
- triangle setup
- rasterization

De rasterization fase is het meest intensief. Een polygoon wordt verdeeld in scanlines (horizontale beeldlijnen), door van boven naar onder langs de randen te interpoleren. De scanlines zelf worden eveneens getekend door waarden hiertussen te interpoleren, en voor elke pixel de pixelshader aan te roepen.

De tekensnelheid kun je effectief verdubbelen door 2 rasterizers te gebruiken die de scanlines om en om tekenen. Toegegeven, dit brengt wel wat extra problemen met zich mee mbt memory access, maar in principe zou je het behoorlijk kunnen optimalizeren aangezien je aan kunt nemen dat bijvoorbeeld de eerste GPU alle oneven beeldlijnen voor z'n rekening neemt, en de tweede GPU alle even beeldlijnen.
In bovenstaand voorbeeld hoeft dus niets dubbel berekend te worden, en die 2e "GPU", welke dus alleen uit een rasterizer bestaat, wordt pas actief als er iets gerasterized moet worden.

Over je verhaal mbt de voodoo5, ik vermoed dat je het over de stappen voor de triangle setup hebt. Maar dat zijn nou juist stappen die niet echt intensief zijn. Bovendien is vertex transformation ook prima af te vangen door daar extra units voor in te zetten, iets wat ATi en nVidia nu al doen

[X-G]

Ik vind de Duo GPU kaarten opzicht wel leuk, maar ik ben bang, dat als straks deze kaarten populair worden, dat de gameontwikkelaars (vanwege de xtra kracht die in de kaart zit) spellen speciaal voor deze kaart zouden gaan ontwikkelen.

Misschien ook een idee om een ondersteuning te bouwen voor twee monitoren, zodat GPU 1 voor monitor 1 rendert en GPU 2 voor monitor 2. Opzicht heeft het niet veel voordelen, maar het scheelt je a) een dure Matrox kaart, en b) bij geen Matrox kaart gebruik een PCI slot.
En voor dual monitor systemen heeft het wel het voordeel dat de GPU's krachtig genoeg zijn om games te spelen, welke de Matrox, naar mijn mening, niet volledig voor zijn gemaakt.

[Beaves]

maar ik ben bang, dat als straks deze kaarten populair worden, dat de gameontwikkelaars (vanwege de xtra kracht die in de kaart zit) spellen speciaal voor deze kaart zouden gaan ontwikkelen.

Dat zullen ze niet doen, omdat ze dan de markt voor de game wel erg klein maken met als gevolg dat ze weinig geld zullen binnenhalen.

Stel dat een ontikkelaar dat daadwerkelijk gaat doen en dus een game maakt die alleen met de snelste GPU's goed draait en dus niet met de mindere, dan kunnen alleen de gamers met een flinke beurs of met aardige ouders de game spelen. Dat schiet dus niet op.

Daarom maken de fabrikanten het altijd mogelijk dat je ook met mindere settings kan spelen, je hoeft niet op 1280x1024 te spelen met 8x FSAA en high-res texture's, je kan ook voor minder kiezen. Dat zal dus absoluut geen probleem worden.

Misschien ook een idee om een ondersteuning te bouwen voor twee monitoren, zodat GPU 1 voor monitor 1 rendert en GPU 2 voor monitor 2. Opzicht heeft het niet veel voordelen, maar het scheelt je a) een dure Matrox kaart, en b) bij geen Matrox kaart gebruik een PCI slot.

Je wilt twee games tegelijk gaan spelen? De huidige videokaarten hebben allemaal al minimaal dual display support en aangezien je geen twee games gaat spelen, is het redelijk zonde als je de twee GPU's allebei een aparte monitor laat aansturen. Als je een dual display setup hebt speel je toch maar op 1 monitor het spel.

[Ruuddie]

Misschien ook een idee om een ondersteuning te bouwen voor twee monitoren, zodat GPU 1 voor monitor 1 rendert en GPU 2 voor monitor 2.

Da's technisch onmogelijk aangezien het ontwerp er op is gebouwd dat de ene GPU de andere aanvult, en niet dat ze appart draaien.
Dan zouden ze dus het hele ontwerp om moeten gooien...

Waar ik bdw het bangst voor ben, zijn de drivers. Ik heb namelijk zo'n gevoel dat die niet al te best zullen zijn, vooral in het begin.

Ook zuipt hij heeeel veel stroom, dat zie je aan het feit dat er 2 (!!) molexen op zitten.

Ik vind de Duo GPU kaarten opzicht wel leuk, maar ik ben bang, dat als straks deze kaarten populair worden, dat de gameontwikkelaars (vanwege de xtra kracht die in de kaart zit) spellen speciaal voor deze kaart zouden gaan ontwikkelen.

Er zit helemaal geen extra kracht in hoor.
Het zijn gewoon 2 GPU's die minder snel zijn dan die van nVidia en ATi, maar als ze gebundeld zijn, kunnen ze wel met de concurrentie mee. Dus niets extra performance of zo, je moet ze gewoon zien als één GPU, want zo wordt ie aangestuurd. Dus niet als een ongebruikte kracht...

[MikeyMan]

Die twee molexen hoeft nieteens te betekenen dat ze zo heel erg verschikkelijk veel stroom zuipen... Denk dat ze er eerder voor zorgen dat de stroomtoevoer gelijkmatig verloopt over beide cores. Bij één molex óf alleen pci stroomtoevoer, zou ik me kunnen voorstellen dat het lastig is om de stroomtoevoer voor beide processoren altijd netjes gelijkmatig te houden...

[Ruuddie]

K heb anders hier een Voodoo5 5500 AGP liggen, en die heeft met z'n 2 GPU's maar één molex nodig hoor

[a.prinsen]

de tweede molex zou ook een molex out kunnen zijn voor "super-power" coolers ?

[Morgion]

Koop een radeon

[SyS_ErroR]

oeiz.. dat ziet er op papier idd goed uit..

Nu maar hopen dat deze nieuwe vga kaarten niet zoveel stroom zuipen, ik vind bijvoorbeeld een extra molex aansluiting op je agp kaart niet egt "gezond"..

* 786562 SyS_ErroR
Betekend dus als je je bios van je agp kaart verkloot dat je die vrij simpel kan vervangen (imho)

[Croga]

ik vind bijvoorbeeld een extra molex aansluiting op je agp kaart niet egt "gezond"..

Kijk dan maar eens goed achterop deze kaart.... Jaja, een Molex aansluiting.....

En echt raar is het natuurlijk niet. Toen de AGP standaard gemaakt werd, had men nog geen flauw idee van al het grafisch geweld van tegenwoordig... Daarnaast zou die power dan door het moederbord geleid moeten worden. Op deze manier voorkom je dat....

[guidooo]

Diercte stroom naar je kaart is zeker wel prettig.

De enige beperking is je voeding die moet natuurlijk wel groot genoeg zijn.

[Verwijderd]

Wat doe je met de firmware van je AGP kaart dan dat je hem geregeld verkloot? :-)

[Beaves]

Hierdoor kunnen beide GPU's met hun eigen geheugen worden uitgerust en zouden ze elkaar niet in de weg kunnen zitten, waardoor de snelheid in theorie verdubbeld.

In theorie ja, in het echt zal dat net zo min het geval zijn als dat het bij dual CPU's het geval is.

Zo is de tweede GPU via een 2,1GB/sec aan de eerste GPU gekoppeld en dus niet direct aan de AGP bus zelf. De door de tweede GPU's berekende frames moeten dus eerst naar de eerste GPU gestuurd worden en dan weer naar de AGP bus worden doorgezonden. Dat brengt een latencie met zich mee.

[Vorlon]

Ehm, de berekende frames gaan naar de monitor. Ik neem aan dat de ramdac van de host om en om de hostdata en de slavedata aanneemt.

[Verwijderd]

Edit: Weggehaald; begripsfout met m'n domme kop...

Echter, ook ik ben heel benieuwd naar de prestaties van deze kaarten.

Edit:
Je hebt gelijk, Countess. De Duo V5 heeft nu 2x zoveel CPU kracht, vergeleken met de V8 Ultra. Het wordt nu alleen dan afwachten hoeveel rendement deze 2de gpu gaat opleveren. Communicatie tussen de twee gpu's, en tussen de twee geheugendelen kost natuurlijk tijd. Er zullen zeker ook dingen dubbel gedaan moeten worden.

Als van de extra 350 MHz er 200 worden verspeeld, dan is het hebben van de 2de GPU natuurlijk niet erg nuttig; dan zal ook een deel van de geheugenbandbreedte weer verloren gaan.

Maar ja, we zien het wel. Als de snelste Volari kaart meekomt met de ATI Radeon 9800 Pro en de snelste nVidia kaart, tegen een lagere prijs, dan is het een mooie concurrent, óók als ATI en nVidia dan al snellere kaarten hebben.

[Countess]

de duo 5 kaart heeft 2 keer zoveel geheugen bandbreedte als de v8 ultra.
dat kan een veel situaties gunstig uit pakken.

daarnaas is het voor de dual v5 kaart ook 2x350mhz core snelheid ipv 1 keer voor de v8 ultra.
dus nog even af wachten welke now echt sneller gaat zijn.

EDIT voor de edit van Firepower : elke GPU gaat aan zijn eigen frame werken, er is dus bijna geen communicatie tussen de GPU's nodig.
en elke GPU word daardoor ook maximaal benut, hij kan namelijk gewoon zo snel mogenlijk zijn frames gaan maken, de andere GPU doet gewoon het zelfde, geheel onafhankelijk van elkaar.

ik vind het een zeer efficient dual GPU ontwerp, met weinig nadelen.
als de GPU's zelf goed presteren (want daar hebben we nog niet zo veel van geheurt) heeft deze dual kaart zeker de potentie om goed te presteren.

[n-i-x]

de duo 5 kaart heeft 2 keer zoveel geheugen bandbreedte als de v8 ultra.

waar haal je dat vandaan?
volgens de tekst hebben ze allebei 256-bits geheugen met dezelfde kloksnelheid.

De geheugenbandbreedte lijkt mij ook het grootste nadeel van de volari-GPU's(met meer pipeline's), aangezien die niet met de fillrate's meeschaalt.

[n-i-x]

volgens de http://www.pcstats.com/articleview.cfm?articleID=908 hebben alleen de Volari-Duo kaarten 256-bit geheugen.

[Verwijderd]

Ben bang dat dit geen succes gaat worden, zon kaart wordt of te duur of te langzaam. Je ziet het ook met dual cpu systeem, er is gewoon een reden waarom dit niet zo veel gebruikt word.

In theorie is het maximaal 2x zo snel maar in de praktijk is het maar een paar % sneller in de meeste gevallen en hooguit in enkele specifieke toepassingen 2x zo snel.

Het is nog steeds het geheugen wat de prestatie en prijs van een videokaart grotendeels bepaald. Als je 2 gpu's theoretisch 2x zo hard wil laten lopen als eentje dan zul je er ook 2x zo snel geheugen op moeten zetten (wat er niet is) of er 2 aparte banken op moeten zetten. Bijvoorbeeld 256MB wat dan inhoud dat je eigenlijk maar 128MB beschikbaar hebt per GPU. Daarnaast kost een 'goede' gpu nog altijd minder als 2 'slechte'. Daar komt dan ook nog een de extra hardware voor de hele besturing van het design en de toegevoegde complexiteit van de driver bij.

Kortom, heel moeilijk om dit ook werkelijk winstgevend te maken.

[Superstudent]

Hm, maar als ze nou eens zoiets weer maken zoals vroeger de Voodoo 2 in SLI mode, dat was zo vet! Dat kan wel een doorbraak zijn, de echte die hard gamers kopen dan toch wel 2 kaarten en zeker weten dat de performance dan wel om te is!

[Verwijderd]

Dan moeten er eerst AGP 3.0 borden met 2 AGP sloten komen. Met PCI Express dat net om de hoek ligt, waarmee zowel AGP en PCI gaat vervangen, denk ik niet dat we dat nog zullen zien.

Misschien is het maken van een soort SLI combinatie wel voor PCI Express handig, omdat op de nieuwe moederborden gewoon alles PCI express zal zijn. Een SLI combinatie zal zeker sneller zijn dan een dual gpu kaart. De Voodoo 2 draaide in SLI mode echt op 190%, vergeleken met een enkele Voodoo 2 (die dan natuurlijk 100% is.)

(Of minstens het grootste dee zal PCI Express zijnl. Ik weet niet zo direct of er nog gewone PCI sloten worden gebruikt voor de achterwaartse compatibiliteit, of PCI Express achterwaarts compatible is, en of men dat gewoon laat vallen.)

[n-i-x]

Een SLI combinatie zal zeker sneller zijn dan een dual gpu kaart.

Waarom denk je dat?
De verbinding tussen de GPU's van de Volari-Duo-kaarten is namelijk even snel als de AGP3.0 bus.

[Countess]

je moet niet dual CPU en dual GPU door elkaar gaan halen,
de oude dual CPU systeem hadden BV voor 2 CPU evenveel bandbreedte naar het geheugen als een single CPU systeem, maar deze GPU's hebben elke hun eigen geheugen. (om te weten of dit een groot voordeel is hoef je alleen maar maar de schaling van de optron te kijken met meerdere CPU's en je weet dat het werkt)
verder werken die 2 CPUs meestal aan het zelfde, waardoor ze soms even nix te doen hebben omdat ze op de andere wachten, maar bij deze dual GPU kaart werkt 1 GPU aan het frame dat zo moet komen en de 2de GPU begint alvast aan het frame dat erna komt, waardoor ze dus nooit op elkaar hoeven wachten.

[Verwijderd]

Ik kan me niet voorstellen dat dit wat gaat worden. Als ze er nu al prototypes van hebben en ze wachten met uitbrengen tot volgend jaar dan issie al achterhaald als hij uitkomt.

[dasiro]

daarom noemen ze het juist een prototype

as in "eerste werkende exemplaar, maar nog niet klaar voor massaproductie"

overigens lijkt het me in de toekomst wel wat te gaan worden, want als je een cpu verbeterd, dan wordt die verbetering per cpu zichtbaar en dus is er indirect een grotere prestatiewinst

[Verwijderd]

Het is misschien een domme vraag maar... hoe kan de software voorspellen wat de volgende frame gaat zijn ? Ik kan me inbeelden dat dit niet zo evident is in een 3D shooter of eenders welk spel waar de gebruiker de beelden beinvloed.
Of is er in de kleine periode dat het ene beeld opgebouwd/getoond wordt al genoeg informatie om de volgende frame te kunnen bepalen ?
Ik wil dit wel eens in werking zien!

[IJs]

Als de ene GPU nog bezig is met de ene frame, is er alweer een andere die gerendered moet worden, die gaat dan naar de tweede GPU.

Die Duo-kaarten zijn voor mij het proberen waard, het ziet er uit alsof het aardig snel gaat presteren. Nu nog maar wachten hoe ze die drivers aan gaan pakken en hoe duur die kaarten nou uiteindelijk worden..

[krijnuh]

Wat voor koeling gaan ze eigenlijk op die kaart monterren of moet je zelf in de winkel een x-tra koeler er bij kopen??

Maar het dual GPU systeem lijkt me wel goed id!!

[Hahn]

Wat voor koeling gaan ze eigenlijk op die kaart monterren of moet je zelf in de winkel een x-tra koeler er bij kopen??

Zoals je op dit plaatje kan zien zullen de kaarten al hun eigen koeling hebben. Deze koeler lijkt heel erg op de Revoltec VGA cooler en dat zijn naar horen vrij goede koelers.

Het zou overigens enigzins vreemd zijn als je zelf koelers bij de kaart zou moeten kopen. In de eerste plaats vanwege dat je de kaart anders niet eens zou kunnen gebruiken, omdat ie natuurlijk wel gekoeld moet worden. En in de tweede plaats: als je de Volari Dual versie neemt is het niet zo simpel om daar een geschikte koeler voor te vinden, aangezien je twee koelers vlak naast elkaar moet hebben en je met een wat grotere koeler daardoor al snel in de knoop komt te zetten.
Ik denk dus als VGA kaarten met twee GPU's erop doorbreken dat er ook VGA koelers komen met twee aan elkaar vastzittende koelers

[Verwijderd]

Klinkt fantastisch, op papier...
Ben heel, heel benieuwd naar de benchmarks.
XGI heeft ze zelf natuurlijk al uitvoerig gebenched anders gooi je jezelf niet voor deze twee leeuwen.
Rest nog de drivers....