Twee Geforce 9800GX2-kaarten in sli-opstelling getest

Dinsdag heeft Nvidia de Geforce 9800GX2 uitgebracht maar de drivers voor quad-sli bleken nog niet bepaald stabiel. Enkele sites wisten echter toch een tweetal van deze kaarten aan benchmarks te onderwerpen.

Onder andere Tom's Hardware probeerde dinsdag twee 9800GX2-kaarten in een sli-configuratie aan de gang te krijgen, maar de resultaten waren volgens de site zo belabberd dat deze pas in een later stadium gepubliceerd zullen worden. Tweaktown kreeg dinsdagmiddag een driver toegestuurd waarmee ze de in totaal vier grafische kernen van twee kaarten wel succesvol konden combineren en ook de Chinese site Zol slaagde hierin.

Bij het draaien van 3dMark06 haalde Tweaktown met de gecombineerde twee Nvidia-kaarten 20.203 punten op een resolutie van 1280x1024. Dat is slechts 548 punten meer dan bij een enkele 9800GX2. Bij de resolutie van 1920x1200 liep het verschil op tot 1794 3dMarks: 19.474 voor de sli-opstelling tegen 17.680 voor de enkele kaart. Crysis bleek in combinatie met de nieuwe driver problemen te geven, maar uit de resultaten die bij op 1600x1200 uit de test kwamen rollen, valt op te maken dat vooral bij hogere settings met quad-sli een aanzienlijk hogere framerate valt te behalen. Unreal Tournament 3 liet echter een geheel ander beeld zien: hier bleek de dubbele 9800GX2-opstelling bij alle resoluties juist langzamer dan een enkele kaart.

De reviewers van Tweaktown hadden nog wat tijd over om de in het testsysteem gebruikte Intel X9650 van 3GHz naar 4,4GHz over te klokken, en in combinatie met quad-sli kon hiermee een 3dMark06-score van 22.352 punten behaald worden. Het Chinese Zol testte elf games met het tweetal topkaarten, en slechts bij de helft viel een verbetering waar te nemen ten opzichte van een enkele 9800GX2. Hoeveel prestatiewinst het bundelen werkelijk kan bieden, zal pas blijken als Nvidia de drivers flink heeft verbouwd, zo luidt de conclusie.

Reacties (80)

[Verwijderd]

Idd "Kees de jong"

Software moet de hardware ook ondersteunen, alleen het vreemde van SLI was dat de game het niet hoefde te ondersteunen enkel dat het overweg kon met de 3DFX Glide driver , 2e kaart erbij en het draaide als een beest in de 1e en 2e pentuim generatie.

Quadcore word in XP en Vista wel benut, enkel applicaties maken er zelden gebruik van, er zijn wel een aantal games die de quadcore gebruiken , 3DMark o.a en Crysis.
Veel games echter zijn niet geoptimaliseerd voor crossfire of SLI , wat eigelijk ook niet hoeft als de driver dit voor zijn rekening nam net als bij de 3DFX Glide driver
of de game nou 16bit of 32bit is ,dat doet er niet zo terzake ,realistische gezien moet elke game in SLI of Crossfire moeten kunnen draaien en een boost van 50% kunnen halen.
Dit ligt puur aan hoe de Driver een game laat comuniceren met 2 kaarten, dit hoeft een game in dit geval niet te doen.
Zelfs een Game als Quake3 uit 1999 ondersteund Multi-Cpu , enkel de parameter en hij draaid als een beest op een P4 en Core 2 duo omdat hij bede cores benut en aanzienlijk performance winst boekt.
Dit geld theoretische het zelfde met SLI en Crossfire enkel de driver moet bepalen hoe de data over 2 GPU's of 2 grafischekaarten moeten worden benut.
dit is best wel complexer als multi-Cpu , bij Crossfire of SLI komt er geen controler aan te pas die tussen de meerder GPU de boel regeld zoals de 9800X2 en 3870X2.
Dan moet dit softwarematige geregeld worden , enkel de kaarten communiceren wel direct met elkaar door de matjes die de twee kaarten met elkaar verbind in SLI of Crossfire (net als bij het Voodoo sli systeem)

[newinca]

Veel games echter zijn niet geoptimaliseerd voor crossfire of SLI , wat eigelijk ook niet hoeft als de driver dit voor zijn rekening nam net als bij de 3DFX Glide driver
of de game nou 16bit of 32bit is ,dat doet er niet zo terzake ,realistische gezien moet elke game in SLI of Crossfire moeten kunnen draaien en een boost van 50% kunnen halen.

Zie boven: Voodoo liet een heleboel dingen NIET toe waardoor SLI theoretisch 100% scaleerbaar was. We zijn 10 jaar later. Technologien zijn veranderd.

Dit geld theoretische het zelfde met SLI en Crossfire enkel de driver moet bepalen hoe de data over 2 GPU's of 2 grafischekaarten moeten worden benut.

Een manier waarop een engine geschreven is, heeft een enorme impact op de theoretische maximum performance die de driver eruit kan halen. Het is niet voor niets dat Crysis met een 1.1 versie uitkwam die onder meer een stuk efficienter was voor zowel SLI als Crossfire. Dat heeft echt niet enkel te maken met het omzeilen van bugs in zogezegde crappy drivers.

[Verwijderd]

Er gaan geruchten dat 3d-paketten zoals Maya, Max, XSI, Lightwave en Houdini binnenkort gebruik zullen kunnen maken van de GPU rekenkracht voor het renderen van complexe scenes.

Een enkele 9800 kaart beschikt over 128 cores die op 1.69ghz draaien die tevens zullen kunnen worden ingezet voor die berekeningen via nVidia Gelato.
Mental Ray (populaire hi-end renderer) is er in elk geval klaar voor, nu nog het 3d pakket zelf en we zijn er.

Dit zorgt wel voor een andere kijk op SLi-systemen en hun 'return on investment'.

Een ding is zeker, van zodra dit op punt staat zal het voor mij minstens een dual SLi worden met dual 6core en 16gb ram.
Hoe de prestatie zal zijn van de 128 cores per kaart vraag ik me wel nog af.
Een lineaire performance boost verwacht ik al zeker niet maar alles wat meer is is beter

Regards
Kurt

[Verwijderd]

Er is voor Nvidia inderdaad al software die gebruik kan maken van de GPU rekenkracht, via de CUDA toolkit van Nvidia (met CUDA drivers natuurlijk). Ik heb de quotes niet helemaal in m'n hoofd maar ik geloof dat ze voor BLAST (tooltje voor biologen en genetici) een 30x speedup over de normale CPU snelheden konden halen. Nu doet m'n server dat nogal vaak, dus ik denk dat ik m'n baas maar eens om zo'n dual 9800x2 ga vragen Als ik dan beloof dat ik thuis ook wel eens wat werk doe....

Ati heeft trouwens dergelijke software/drivers ook.

Het lijkt me dus niet zo lang meer duren voordat software die zwaar op het numbercrunchen hangt ook GPU optimalizaties mee gaat krijgen.

[Verwijderd]

Mja ze zeggen wel vaker dat de drivers de boosdoener is en dat er daardoor slechte prestaties worden neergezet.

heel dat 2X ofwel 2gpu's op een kaart bakken is niet effiecient, gezien de prestaties en stroom verbruik en de kosten om zo'n kaart te kopen.
Het Voodoo tijdperk heeft dit al bewezen, meerdere GPU's op 1 kaart te bakken, warmte probleem ,hoog stroom verbruik en duur in aanschaf.
de performance is niet verdubbeld door een 2 GPU te plaatsen, net zo min als een Core 2 Duo of multi proccesors platforms.
Het vreemde is dat Voodoo in SLI beter presteerde als de SLI van nu, met 1 Voodoo kaart en 8MB kon je op 16bit 800x600 met constande 47Fps draaien en met Voodoo SLI
1024x768 16bit en constande 57Fps zonder drops.

Later kwamen de multi-Gpu varianten uit van Voodoo en hier bleek al dat het niet rendable genoeg was gezien de kosten en performance.
Dus ik snap deze Hype niet , X2 en SLI ,Crossfire.
Veel spellen halen 20% meer performance of op zijn hoogst 50% rendement van 2 grafischekaarten in SLI of Crossfire.

2x een 9800X2 en dan enkel Crysis boekt winst , zelfs 3DMark geef luteloze winst voor dit kostenplaatje van bijna 1000euries !!
Kom op Nvidea en ook ATI, kunnen jullie nu echt geen betere technologie op de markt brengen die wel kick ass geeft op het scherm ?
Echt revolutionaire harware is het niet ,dit had 3DFX jullie ook wel kunnen vertellen vanuit het Voodoo tijdperk maar toch kopen mense deze grafischekaarten zonder te beseffen dat je oude technologie in huis haalt die opgewaardeerd op de mark is gekomen en eigelijk is achterhaald en niet rendable is tegen over de kosten en performance wist.

[newinca]

Het vreemde is dat Voodoo in SLI beter presteerde als de SLI van nu, met 1 Voodoo kaart en 8MB kon je op 16bit 800x600 met constande 47Fps draaien en met Voodoo SLI
1024x768 16bit en constande 57Fps zonder drops.

Dat is helemaal niet vreemd. Ten tijde van de Voodoo SLI bestond de mogelijkheid niet om render-to-texture to doen. Dat maakt SLI extreem eenvoudig.

Je vergelijkt technologie van 10 jaar (!) geleden met die van nu. Misschien toch eens twee keer nadenken?

En wat 3Dmark06 betreft: is het je al opgevallen dat 3Dmark het laatste jaar niet meer representatief is voor praktische vergelijkingen? R600 had dezelfde score als een 8800GTX. Go figure...

[Reactie gewijzigd door newinca op 24 juli 2024 13:33]

[eedaan]

Wat een kracht, 60 % winst met SLI t.o.v. geen SLI met crysis.. Jammer alleen dat 2 van die kaarten totaal 1000+ euro kosten..

[DaOverclocker]

Inderdaad in Crysis:
1600x1200@veryHigh@vista
SLI ~26FPS
Quad ~42fps

Dat is dus mooi van niet speelbaar tot wel speelbaar. Op High gaat het van 40 FPS naar 60FPS, ook een hele nette boost. CoD4 laat ook wel leuke getallen zien. Dat zijn betere voorbeelden als die 3dmark scores.

[Verwijderd]

er is een programma gemaakt waardoor je mooi beeld en een redelijk hoge fps krijgt

http://www.crymod.com/thr...89319bebecc0016aa888ca5ac

ik hoop als je der wat aan hebt

[omgwtfbbq]

Bij hogere resoluties lijkt alles mooier zonder dat je Anti Aliasing aan hebt staan, en een hogere resolutie kost minder rekenkracht dan Anti Aliasing.

[semicon]

ja kracht op 1 spel ja... want overall presteerd sli dus gewoon bagger.

ik bedoel:

Bij het draaien van 3dMark06 haalde Tweaktown met de gecombineerde twee Nvidia-kaarten 20.203 punten op een resolutie van 1280x1024. Dat is slechts 548 punten meer dan bij een enkele 9800X2.

Da's toch om te janken

[HugoBoss1985]

Het gaat dus niet om SLI, maar om Quad SLI.
Sli zelf presteert heel erg goed.

[Jeanpaul145]

Ik vraag me af waarom SLI zo slecht schaalt?

Met 2 kaarten presteert t goed, maar met 4 weer bagger? ik zou denken dat zelfs met de toegenomen overhead de prestaties flink zouden moeten toenemen.

Hiernaast vind ik het ook echt raar dat de drivers verbouwd moeten worden zodat game X behoorlijk kan functioneren. Als de architectuur een beetje deugde zou dit denk ik geen probleem mogen zijn.

[newinca]

Het fundamentele probleem is dat de DX7,8,9,10 driver architectuur niet ontworpen is om niet-coherente GPU's parallel te zetten. Het doet er niet toe of het SLI of Crossfire is, de huidige multi-GPU drivers zullen altijd een hack blijven waarbij een heleboel manuele profiles nodig zijn om het te kunnen laten werken.

De drivers gaan uit van een model waarbij de commando's in een pushbuffer lineair worden uitgevoerd. Sommige latere commando's hangen af van het resultaat van een vorig commando. Dat geldt voor een heleboel aspecten: render-to-texture, pixel overlap, vertex processing etc. Daarbij komt dat dit soort interlocks speelt zowel binnen hetzelfde frame als tussen opeenvolgende frames.

Bijvoorbeeld: als een engine eerst afzonderlijk naar een buffer rendert voor een reflectie en vervolgens die buffer gebruikt in het finale beeld om een spiegel te renderen, dan moet je dus wachten met dat finale beeld tot de texture compleet is.

Geen probleem op een enkele GPU, wel op een multi-GPU. Want plots heb je de keuze: ofwel ga je de texture enkel op GPU A renderen en transferreer je die texture vervolgens over PCIe naar GPU B ofwel render je de texture in beide GPU's tegelijkertijd, maar dan kan je enkel het finale beeld versnellen en heb je geen acceleratie tijdens het renderen van de texture.

In het eerste geval wordt bandbreedte van de PCIe bus een probleem. In het tweede geval werkt het meestal nog wel voor 2 GPU's maar voor meerdere wordt de texture rendering progressief het element dat het meeste rekentijd in beslag neemt en loop je tegen Amdahls Law aan.

Dit is een voorbeeld van intra-frame dependencies. Dit probleem stelt zich niet stellen als je GPU B al aan het volgende frame laat werken en dat is dan ook de mode waarin de meeste multi-GPU's werken (Alternate Frame Rendering).

Maar bij AFR heb je een problem van inter-frame dependencies: in veel gevallen zal een engine het vorige beeld gebruiken als texture voor het volgende. In dat geval kan je dus pas beginnen als de benodigde informatie van het vorige frame al af is EN moet je die data ook nog eens over de PCIe sturen. En je verbruikt nog eens meer frame buffer geheugen ook.

De enige manier om dit echt onder controle te houden is ervoor te zorgen dat engine developers zich bewust zijn van dit soort limitaties en dependencies zo schedulen dat ze op zijn minste niet al te veel impact hebben. Dat is niet altijd even eenvoudig...

Een meer radikale oplossing is om meerdere GPU's toegang te geven tot een vereenigde adresruimte met een gigantisch brede link ertussen. Maw: maak het mogelijk dat GPU A zonder al te veel schade de data van GPU B direct kan aanspreken waardoor 2 GPU's min of meer als 1 GPU kunnen fungeren. Volgens de geruchten is dat waar ATI aan het werken is, maar het is niet evident dat dit op dit moment technisch al haalbaar is.

Nog radikaler zou zijn om de driver 100% multithreaded te maken, met multi-threaded pushbuffers, waarbij je onafhankelijke renders kan lanceren en die pas op het einde samenvoegt. Misschien iets voor DX12? :-)

Anyway, het is dus absoluut niet vreemd dat het slecht schaalt van 2 naar 4: je loopt simpelweg vlugger tegen de zwakste schakel aan.

[Reactie gewijzigd door newinca op 24 juli 2024 13:33]

[justice strike]

Als je programmeerd blijft de multigpu implementatie onzichtbaar voor de programmeur. Immers maakt het niets uit of er een enkele kaart of meerdere kaarten gebruikt worden, dat wordt allemaal door directx en de driver afgehandeld.

Het is waar dat je met kennis van de onderliggende structuur veel betere programma's kunt schrijven, maar het blijft anders dan echt daadwerkelijk 2 verschillende gpu's apart programmeren.

Echter zou dit ook niet moeten, want gpu's zijn zodanig van structuur dat ze taken uitvoeren die perfect geparalleliseert kunnen worden. Zoals je aangeeft is de bottleneck dan idd het geheugen. Maar met sli op een board kun je daar ook nog wel wat aan veranderen.

[Reactie gewijzigd door justice strike op 24 juli 2024 13:33]

[newinca]

Als je programmeert blijft de multigpu implementatie onzichtbaar voor de programmeur. Immers maakt het niets uit of er een enkele kaart of meerdere kaarten gebruikt worden, dat wordt allemaal door directx en de driver afgehandeld.

"Als compiler schrijver maakt het helemaal niet uit hoe de CPU werkt. Die processor voert je instructies gewoonweg uit. Het maakt niets uit over die CPU super-scalar of deeply pipelined is."

Dit soort opmerking zou je een dikke nul geven op een computer science examen.

Net zoals een CPU een ISA ondersteunt en uitvoert, voert de driver grafische instructies uit. Maar het is ongelooflijk eenvoudig om daar extreem dom in te zijn. Als de compiler cpu instructies zo achter elkaar zet dat je de ene register hazard na de andere veroorzaken, dan kan zelfs een out-of-order scheduler daar niets aan verhelpen.

Net hetzelfde met een GPU driver. Waarom denk je dat zowel Nvidia en (in mindere mate) ATI een uitgebreid developers relations programma hebben? Die doen echt meer dan stickertjes op de verpakkingsdozen plakken: hun taak is om ontwikkelaars op te voeden over hoe je o.a. efficient de driver aanspreekt. En je kan er donder op zeggen dat ze daarbij rekeninghouden met SLI/Crossfire.

... maar het blijft anders dan echt daadwerkelijk 2 verschillende gpu's apart programmeren.

Heb ik dan iets anders gezegd? Ken jij iemand die voor 2 GPU apart programmeert?

Maar met sli op een board kun je daar ook nog wel wat aan veranderen.

Daar kan je enkel iets aan veranderen met een spectaculaire architecture aanpassing. Dat is absoluut niet evident, al was het maar omwille van de grote area cost.

[Reactie gewijzigd door newinca op 24 juli 2024 13:33]

[justice strike]

mwa je haalt nu wel 2 dingen door elkaar. Een compiler is wel heel wat anders dan een hll. games worden nu eenmaal in hll geschreven en niet (meer) in assembler.

Daarbij maakt het idd niet uit als je een cpu hebt die super-scalar is of deeply pipelined. Dezelfde compiled asm zal altijd draaien (386 code draait nog steeds op de huidige processoren). Simpel voorbeeld: er bestaat een compiler compiler die de instructieset als input neemt en daar een compiler van bouwt. Voorderest weet de compiler compiler helemaal niets van de interne werking van een cpu, toch werkt het allemaal.

Dat het niet altijd even efficient is, dat is een ander puntje, maar je kunt ook niet verwachten dat men games programmeert die alle toekomstige videokaarten even efficient benut.

[Reactie gewijzigd door justice strike op 24 juli 2024 13:33]

[newinca]

mwa je haalt nu wel 2 dingen door elkaar. Een compiler is wel heel wat anders dan een hll. games worden nu eenmaal in hll geschreven en niet (meer) in assembler.

Dit heeft absoluut niets te maken met het verschil tussen assember vs hll. (Mijn excuses: ik verdacht je er initieel toe in staat om details te kunnen onderscheiden van grotere concepten. Quod non?)

Dit gaat erom dat een in beide gevallen het bestaan van een specificatie niet automatisch resulteert in een optimale uitvoering.

Dat het niet altijd even efficient is, dat is een ander puntje, ...

Dat is nu net wel het punt...

... maar je kunt niet verwachten dat men iets programmeert dat alle toekomstige videokaarten even efficient benut.

Precies. En laat de hele bedoeling van mijn posting hierboven nu net zijn dat men om technische redenen niet zomaar kan verwachten dat bestaande spellen zonder problemen kunnen scalen op een SLI/Crossfire opstellen.

Wat is het eigenlijk dat je probeert uit te leggen?

[justice strike]

Ik begrijp precies wat je bedoelt, ik probeer alleen wat nuances te brengen aan datgene wat je uitlegt als nonsense namelijk:

Applicaties kun je eigenlijk niet maken voor SLI, aangezien je als spelmaker geen idee hebt hoe de grafische informatie die je via DirectX of OpenGL verwerkt wordt in de hardware.

het klopt in essentie wel, je kunt er rekening mee houden, maar je kunt niet zelf bepalen hoe een programma sli benut.

[newinca]

Ik begrijp precies wat je bedoelt, ik probeer alleen wat nuances te brengen aan datgene wat je uitlegt als nonsense namelijk:

Applicaties kun je eigenlijk niet maken voor SLI, aangezien je als spelmaker geen idee hebt hoe de grafische informatie die je via DirectX of OpenGL verwerkt wordt in de hardware.

het klopt in essentie wel, je kunt er rekening mee houden, maar je kunt niet zelf bepalen hoe een programma sli benut.

Dat kan je grotendeels wel: het zijn al bij al relatief simpele technologien. Maar het hoeft zelfs niet: als je voldoende rekening houdt met de beperkingen, krijg je automatisch een (veel) beter resultaat. Net zoals je als compiler schrijver voor een CPU niet precies hoeft te weten hoe de out-of-order processing werkt: het is voldoende te weten wat de beperkingen zijn om er rond te werken.

Het is best mogelijk dat dit voor een aantal algoritmes niet theoretisch mogelijk is en dat verklaart meteen waarom je in de praktijk weinig spellen ziet dit meer dan 90% scalen. En waarom je scaling drastisch in elkaar zakt als je naar meer dan 2 GPU's gaat.

Edit:

Maar in principe kan de gpu architectuur nagenoeg zonder performance verlies schalen (als je kijkt naar de manier van verwerken van pixels, niet naar de andere issues zoals memory etc..)

In principe kan dat voor een SLI/Crossfire architecture zoals ze nu bestaat per definitie niet. Zelfs met een 100% bugvrije en perfecte driver.

[Reactie gewijzigd door newinca op 24 juli 2024 13:33]

[justice strike]

ja ok, maar dan hou je rekening met randvoorwaardes. maar je bepaald niet hoe iets in sli uitgevoerd wordt. Ik denk dat hij dat probeerde te zeggen.

[Verwijderd]

@newinca

Leuk verhaal... maar de resultaten van AMD's 4x Crossfire laat zien dat het gewoon niet klopt. Met 4x Crossfire krijg je prestatie winsten van 3,2x een enkele kaart. (Zie de berichtgeving hierover een paar weken geleden.) Dat is dus gewoon heel erg goed!

Het is dus onder DX9 en DX10 prima mogelijk om een goed schalende 4xCrossifre/SLI te bouwen. Dat NVidia dat niet voor elkaar krijgt, zegt dus alles over NVidia, en niets over DirectX.

Die 3,2x was nieteens een harde limiet... het 'probleem' was gewoon dat de spellen niet genoeg GPU gelimiteerd waren, om nog hoger te scoren. Logisch... Hoe sneller de GPU, maar meer je spel CPU gelimiteerd wordt. Dat kun je tegengaan door hogere resoluties te gebruiken, maar er zitten grenzen aan. Niet zozeer vanwege de hardware, maar ook vanwege de structuur van het spel.

Een meer hardwarematige limiet is natuurlijk dat een Crossfire systeem wel de shader kracht van je grafische systeem verhoogt, maar niet zaken als bijvoorbeeld de geheugen bandbreedte. Dat zal van het spel afhangen in hoeverre dat een bottleneck wordt. De meeste engines schalen behoorlijk goed, maar Crysis is zo'n uitzondering die erg slecht schaalt. Die zal dus waarschijnlijk niet (meer) shader gelimiteerd zijn in SLI/Crossfire opstellingen...

[newinca]

@AHBdV:
Het verbaast me absoluut niet dat iemand met zo'n idiote opmerking zou afkomen.

Jouw redenering noemt men 'cherry picking': je kiest er een resultaat uit en poneert dat dan als een algemene stelling, terwijl er tientallen andere voorbeelden zijn waarbij je overduidelijk geen versnelling ziet van 3.2.

Als je iets zou begrepen hebben van wat ik geschreven heb, dan zou je zelf kunnen afgeleid hebben dat het niet onmogelijk is om nagenoeg perfect te scalen: het kan namelijk wel, maar dan enkel als je bepaalde effecten achterwege laat. Dit is precies de reden waarom Voodoo SLI zo goed werkt: in die tijd was het simpel weg niet mogelijk om render to texture te doen of vertex schader. Je had een volledige lineaire niet programmeerbare pipeline. Geen enkele feedback loop, dus ook geen enkele interlock.

En dat is nu net wat ik bedoelde met het opvoeden van engine programmeurs: in sommige (maar niet alle!) gevallen kan je een effect zodanig herschrijven dat er minder afhankelijkheden zijn tussen de render stappen, zodat het beter parallelizeerbaar is.

Zoals al eerder gezegd: als Crytek met een versie 1.1 uitkomt die plots een stuk sneller is dan versie 1.0 op dezelfde drivers, ligt dat dan aan de driver of aan de engine? Probeer dat eens uit te leggen. Of beter, laat maar zitten...

[reb65]

Tja dat is denk ik het probleem van SLI de optimalisaties zitten niet in de driver maar in de applicaties. Beetje het zelfde verhaal als quad core vs dual, of single core.

[YopY]

Applicaties kun je eigenlijk niet maken voor SLI, aangezien je als spelmaker geen idee hebt hoe de grafische informatie die je via DirectX of OpenGL verwerkt wordt in de hardware.

[newinca]

Applicaties kun je eigenlijk niet maken voor SLI, aangezien je als spelmaker geen idee hebt hoe de grafische informatie die je via DirectX of OpenGL verwerkt wordt in de hardware.

Sorry, maar dat is onzin.

De regels voor zowel SLI en Crossfire zijn zeer duidelijk en voor 95% identiek: vermijd zoveel mogelijk dependencies tussen afzonderlijke render buffers. Indien je die wel hebt, probeer ze dan op z'n minst op een intelligente manier te orderen in de tijd.

Zie ook mijn posting hieronder.

[Reactie gewijzigd door newinca op 24 juli 2024 13:33]

[justice strike]

nope, drivers zijn ruk en het feit dat de pci express bus gewoon niet zo snel is als on board memory. Dus communicatie is gewoon langzaam. Maar in principe kan de gpu architectuur nagenoeg zonder performance verlies schalen (als je kijkt naar de manier van verwerken van pixels, niet naar de andere issues zoals memory etc..)

[reb65]

Quad sli als je kijkt naar de cores, Sli als je kijkt naar de kaarten. Is dus eigenlijk maar net hoe je het bekijkt. Eigenlijk maakt het niet uit hoeveel cores je hebt het is en blijft sli..

Als je een enkele 9800 x2 vergelijkt met 2 losse tegenhangers (8800 gts 512? was het volgens mij) presteren deze beter, en zijn ook nog eens beter te koelen dan zo'n 9800 x2.

Gote voordeel van de 9800 x2 was eigenlijk dat je 2 van deze kaarten in sli kon plaatsen in nog enigsinds betaalbare moederborden (zonder 4 pcie sloten). Waardoor je dus je quad sli opstelling krijgt, alleen een sli opstelling van deze kaarten presteert dus blijkbaar bagger wat mij doet afvragen wat de toegevoegde waarde is van deze kaarten.

[Reactie gewijzigd door reb65 op 24 juli 2024 13:33]

[Admiral Freebee]

Het blijft eigenlijk quad SLI want de twee GPU's op elke kaart zijn onderling ook via SLI verbonden. Het zijn nog altijd geen dualcore GPU's.

[justice strike]

dual core gpu's zullen ook nooit komen.

[YopY]

In principe zijn de gpu's van tegenwoordig al multicore, met 128+ shader units die eigenlijk gespecialiseerde cores zijn. Daarnaast, sli-on-chip is niet zo'n vreemd idee. Ook met bijvoorbeeld AMD en ATI, waarbij AMD zijn multicore technologie kan gebruiken voor zijn grafische kaarten.

[justice strike]

sli on chip? waarom zou je sli onchip maken als je gewoon van alle shaders 2 keer zoveel kunt maken. SLI neemt onnodige ruimte in beslag die je veel beter kunt gebruiken.

Een gpu werkt heel anders dan een CPU dual core zal wel werken met een CPU, maar dat is omdat een CPU eigenlijk bedoelt is om 1 thread tegelijk te behandelen. een GPU is een stream processor, die kan streams verwerken en werkt eigenlijk al in parallel (namelijk meerdere pixels kunnen tegelijk berekent worden.

[darkcarlaza]

dual core gpu's zullen ook nooit komen.

“640K of memory should be enough for anybody”

[Reactie gewijzigd door darkcarlaza op 24 juli 2024 13:33]

[newinca]

dual core gpu's zullen ook nooit komen.

“640K of memory should be enough for anybody”

Compleet irrelevante poging om intelligent uit de hoek te komen.

Single die dual core GPU's zullen er nooit komen omdat het technische nonsense is. GPU's zijn namelijk al embarrassingly parallel wat betreft shader core, texture units en ROPs.

[darkcarlaza]

Mijn ongelooflijk overtuigende spijtbetuiging laat ik voor het gemak even achterwege...

Het is inderdaad een compleet irrelevante opmerking, niet geplaatst om intelligent over te komen. Kijkje in m'n kop zou aardig zijn, maar dat lukt niet op deze afstand. Bij deze dan maar, wat een eikelige reactie zeg, gelijk zo op de persoon, bah.

Marketeers zorgen er wel voor dat one-die dual core wordt ontwikkeld, al houdt het juist de ontwikkeling ermee tegen. Dit is een vergelijkbaar verhaal met Megapixels, meer is beter, wat totale onzin is.

Dat een GPU core eigenlijk een multi core opzich is, geeft inderdaad aan dat het onnodig zou moeten zijn, ruimteverspilling is, er een tweede core bij te hangen.

Dual Core GPU's komen er wel, al is het beter van niet, dat moet jij kunnen beamen als chip-bakker. Gaan de ontwikkelingen in jou bedrijf niet ook die kant op?

[justice strike]

dat is iets totaal uit context. dual core gpu heeft totaal geen nut. Met dezelfde diesize kun je veel nuttigere dingen doen dan dual core implementeren.

[TheSiemNL]

jij heb een goed band met Ati, en Nvidia denk ik. De cpu fabrikanten willen graphics in de cpu, de graphics fabrikanten willen meer kracht in de GPU. Ik denk dat er uiteindelijk wel meerdere cores zullen zijn met de GPU.

[newinca]

Zoals door verschillende posters al vermeld: GPU's zijn al massaal parallel. Een dual-core GPU is onzinnig.

Neem nu een 8800GT:
- die heeft 8 clusters. Elke cluster heeft 2 multi-processoren. Elke multi-processor heeft 8 processoren. In totaal: 128 processoren.
- elke cluster heeft ook een aantal texture units
- er zijn 4 memory controllers (elke 2x32 bits) met daaraan een raster unit gekoppeld.

Begint het stilaan te dagen? Als je de performance wil vergroten, dan zal elk weldenkend ingenieur het aantal units verhogen. In plaats van 8 clusters steken ze er 12 in. Of 16. In plaatst van 4 memory controllers, 6 (zoals de 8800GTX) of later misschien 8.

Vergelijk een 8800GT met een 9600GT: heeft net dezelfde specs, behalve dat die laatste 4 clusters heeft ipv 8, terwijl het aantal geheugen controllers en raster units hetzelfde is.

Begint het stilaan te dagen? Om bij een GPU binnen dezelfde generatie de performantie te verhogen, is het een kwestie van gewoon een van de functie blokken te kiezen en die te vermeerderen of te verminderen. Zo eenvoudig is dat. Je heeft niet eens te verdubblen of te halveren: het is zou perfect mogelijk zijn om van 8 clusters naar 6 te gaan. (Probeer dat maar eens met een dual core CPU.)

Het concept 'dual-core' zoals gebruikt bij een CPU in de zin dat je meerder CPUs op een die plakt is technische nonsense: GPU zijn al 10 jaar massaal parallel.

[Reactie gewijzigd door newinca op 24 juli 2024 13:33]

[_Thanatos_]

dual core gpu's zullen ook nooit komen.

Hij zou best eens gelijk kunnen hebben. Het is gewoon efficienter om een enkele GPU meer te paralleliseren, em dus "breder" maken in technische zin. Twee cores is gewoon een goedkope manier om extra kracht toe te voegen. Bij CPU's ligt dat nou eenmaal heel anders.

[Tazzios]

iedere core heeft z`n eigen geheugen nodig daar gaat j ekosten besparing.

[smocho]

Het is gewoon quad SLI, geen SLI, ook niet "eigenlijk gewoon SLI".
Het zijn 4 pcb's, 4 gpu's, dus quad SLI.
De drivers van SLI werken dan ook niet op Quad SLI zoals te lezen valt....

[gise]

Anderzijds gebruik je zo'n opstelling natuurlijk om te gamen dus als het in game(s) 60% prestatiewinst opleverd tegenover bijna niks in benchmarks is er opzich nog weinig om over te klagen

[ZpAz]

Zoek jij eens reviews op van echte SLI opstellingen bijvoorbeeld 2x een 9600GT een gemiddelde toename is dan toch wel 75 - 80%. In sommige games zelfs rond de 95%.

Dit is een QUAD SLI opstelling, een X2 is al een dubbele kaart.

SLI draai ik zelf ook met (7900gs 2x) en performancewinst is er zeker wel in games.

[batavier]

Met de drivers wel ja, nog even wachten op goeie drivers dus. Blijft jammer dat het toch zo'n EUR 1000 kost om dit in je PC'tje te kunnen stoppen.

[eedaan]

Synthetic benchmarks zijn zoiezo om te janken, ga de benchmarks van een Q6600 tegen een E8500 maar eens vergelijken - 3D games tegen Synthetic benchmarks.

[Jackybeer]

Volgens Toms hardware is de 9800x2 de snelste kaart van de wereld, gemiddeld is het verschil ook veel groter dan de HD-3870x2. De 9800x2 is zwak op de hoogste resoluties men had meer verwacht van deze kaart. De functies zijn niet veel veranderd t.o.v. de geforce 8. Teleurstellende prestaties antialiasing op de hoogste resolutie. Geen DirectX 10,1 ondersteuning. En ze vinden de prijs te hoog.

[Reactie gewijzigd door Jackybeer op 24 juli 2024 13:33]

[Verwijderd]

Crysis is mede door de Motionblur prima speelbaar op 25+ frames per sec.

[innerchild]

prima speelbaar op 25 fps ? sorry met alle respect maar dat is echt een opmerking van een huis tuin en keuken speler. 25 fps voor een fps shooter is gewoon not done...

[DoubleDot]

als je niet online speelt en op een niet te hoog moeilijkheids niveau is dit perfect speelbaar.

Let vooral op SPEELBAAR.

Natuurlijk wil je best 60fps + bij een fps online ( dat zeker )

[Verwijderd]

Ik denk dat het feit dat de software achter de hardware ontwikkelingen aanstrompelt in dit verhaal ook meespeelt.

Quad core of Quad GPU is leuk als de software er klaar voor is

[Boxman]

Wat vreemd toch, dat in alle reviews vand e HD3870 x2 de 8800Ultra in bijna alles verslagen wordt, en hij in deze review van tomshardware ineens significant langzamer is. Zegt wel weer wat over de betrouwbaarheid.

Ik zelf geloof al heel lang niet meer in de betrouwbaarheid van de zogenaamd 'onafhankelijke' reviewsites. Reken maar dat nVidia een heel dik budget heeft om dit soort dingen af te kopen, als goede reclame, waarna er nooit bij nVidia zelf kan worden aangeklopt omdat 'zij dat zelf nooit hebben beweerd'. Slim, dat wel, maar ik ben ervan overtuigd dat het grootste deel van dat wereldje net zo corrupt is als de rest van de wereld

[Verwijderd]

Moet je bij de 9800X2 persé de 8pins voeding connector gebruiken? of kun je ook gewoon daar een 6pins indoen? dus 2 keer een 6pins pci-e connector ipv 6 en 8 pins...

die info kan ik nergens zo echt terugvinden bij de fabrikanten.
Wil op zich wel die MSI 9800x2 maar dan moet ik wel eerst weten of ik die 8pins echt MOET gebruiken

[Reactie gewijzigd door Verwijderd op 24 juli 2024 13:33]

[svenk91]

er zijn geloof ik 6 naar 8 pins converter dingetjes

[Serendipity]

Ik had hetzelfde met mijn HD2900XT, maar met 1 8-pins en 1 6-pins werkt hij perfect...


Gewoon googlen en je vindt vanzelf het goede resultaat...

[Reactie gewijzigd door Serendipity op 24 juli 2024 13:33]

[Decile]

de 6 pins kan 75 watt wegtrekken maximaal terwijl dat een 8 pins het dubbele zelfs kan, dus zon maximaal al 300 W als je het allemaal uitrekent totaal, hij trekt wss maar net 200 W weg dus een 2 x 6 pins moet gewoon genoeg zijn iig,

ik heb hier ook al mee gezeten omdat mijn voeding heeft 1 x 8 pins en 2 x 6 pins, als ik een 9800 GX2 koop dan zet ik hem wss ook meteen in SLI, dus 2 van die kaarten, daarom was ik al aant googlen geweest naar een oplossing voor die ene 8 pin die mn voeding mist, maar er zijn iid 6 naar 8 pins converters en ik hoop eigenlijk iets te vinden met een 4 x molex > 1 x 8 pin pci-e adapter, dat zou iig helemaal mooi zijn, dan kan je allebei de kaarten van genoeg juice voorzien.

[Nokian95dude]

Deze kaart is niks mis mee. Het zijn toch de drivers die de gpu moeten aansturen en ik weet gewoon zeker dat die gewoon niet alles uit deze kaart kunnen halen op dit moment. Je maakt mij niet wijs dat 2 kaarten langzamer zijn dan 1 kaart bij sommige games.
Dat kan gewoon niet. Laten we nu de geupdate drivers even afwachten voor we echt een oordeel kunnen vellen.

De resultaten zijn leuk voor een eerste test maar tis mij wel duidelijk genoeg dat deze kaart veel meer kan dan tot nu is bewezen.