AMD: Weitere Dual-GPU-Karten geplant

Stegan

Redakteur
Hardwareluxx Team
Thread Starter
Mitglied seit
16.12.2005
Beiträge
16.274
Ort
Augsburg
<p><img style="margin: 10px; float: left;" alt="amd" src="images/stories/logos/amd.jpg" height="100" width="100" />Dank der Verwendung zweier Grafikprozessoren auf nur einem Printed-Circuit-Board (PCB), gelang es <a href="http://www.amd.com/de-de/" target="_blank">AMD</a> in der Vergangenheit schon mehrmals starke Geschütze gegenüber seinen Konkurrenten aufzufahren. So holte man – wenn auch nur für kurze Zeit – mit der ATI Radeon HD 4870 X2, welche in unserem <a href="http://preisvergleich.hardwareluxx.de/" target="_blank">Preisvergleich</a> derzeit ab <a href="http://preisvergleich.hardwareluxx.de/a355516.html" target="_blank">etwa 324 Euro</a> zu haben ist, die Performancekorne in die eigenen Reihen. Doch damit soll noch lange nicht Schluss sein. Wie die...<p><a href="/index.php?option=com_content&view=article&id=12171&catid=38&Itemid=101" style="font-weight:bold;">... weiterlesen</a></p>
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Da kann mann nur hoffen das Sie das Powerplay verbessert haben und die Karte von haus aus schon sparsam ist, top währe natürlich wenn AMD dann auch mal die Treiber in den Griff bekommt.
 
Kein Launch-Termin ?:-[
Soll einfach das machen wo meine jetz. Graka auch macht : laufen, und zwar nicht zu knapp
 
@sualk027: Sag mal hast Du das gelesen, was Du da geschrieben hast? Von soetwas bekommt man ja Augenkrebs!

btt: Leistung steigern, Stromverbrauch senken und Lautstärke minimieren sind die grossen Ziele würde ich mal meinen. Nen neuer Stockkühler mit nem gescheiten Konzept wär mal Klasse. So in der Art wie ein AC S1 mit Abdeckung und Axiallüfter. Das wär doch mal was.
 
Bist sicher dass du nicht schon vorher Augenkrebs gehabt hast ?
Und selbst wenn sie es schaffen die Chipeffiziens dahingehend zu steigern dass mehr Leistung weniger Saft zieht würde dies wieder in mehr Leistung investiert, ist ja schliesslich die Performance-Liga. Für nen Stromspar-Rechner gibts noch anderes.
 
Da bin ich absolut kein Freund von, Microruckler und Treiberprobleme sind vorprogrammiert...!
 
Auf kurz oder lang ist das aber die einzige möglichkeit schnell mehr performance zu bekommen, umso schneller man die entwicklung darin betreibt, umso besser für uns Kunden.

Ich finde AMD macht das genau richtig, ..
 
Jaein, man kann es so wie Lord Quas beschrieben hat sehen, oder man sieht es aus folgender Sicht:
Es ist schon ein Fortschritt, wenn ein Hersteller 2 GPUs auf ein PCB packt und die Karte somit mehr Leistung hat. Der Kunde hat etwas davon. Wenn der Hersteller aber diesen Schritt gehen muss nur um mehr Leistung zu erzielen, dann ist das mMn nicht so ein riesen Fortschritt, als wenn eine Karte mit nur einer GPU die selbe oder annähernd die selbe Leistung bringt.

Vllt. gehen die GraKa Hersteller irgendwann den selben Weg wie AMD und Intel in Sachen Multicore. Sprich, sie vereinen mehrere GPUs auf ein PCB. Natürlich kann jetzt jemand ankommen und behaupten, die jetzigen GPUs bestehen ja aus vielen Kernen usw., das meine ich nicht damit; sondern, dass sie den selben Weg gehen wie Intel mit Larabee.
 
ansich ist es nicht schlecht wenn man kleinere gpus baut um diese zusammen zu schalten, bessere ausbeute usw.
nur leider gabs da mal einen hersteller, der genau diese taktik verfolgt hat und daran zu grunde ging. zuletzt verushcte er eine 4-gpu-karte zu bauen, von welcher es jetzt weltweit 66 laufende exemplare gibt :fresse:
ich glaub jeder weiss, wen ich meine ;)
 
Zuletzt bearbeitet:
ansich ist es nicht schlecht wenn man kleinere gpus baut um diese zusammen zu schalten, bessere ausbeute usw.
nur leider gabs da mal einen hersteller, der genau diese taktik verfolgt hat und daran zu grunde ging. zuletzt verushcte er eine 4-gpu-karte zu bauen, von welcher es jetzt weltweit 60 (?) laufende exemplare gibt :fresse:
ich glaub jeder weiss, wen ich meine ;)

um diese dann auf einem Die zu vereinen. Gute Begründung: keine Mikroruckler ;)
SLI damals bzw. der Vorgänger davon war ja richtig effizient...
 
wiso damals zu Ur SLI Zeiten wurde es noch genutzt dammit man höhere Auflösungen Spielen Konnte z.b VooDoo2 mit zwei war 1024x768 drin whusaaa :eek:
 
Muaah... ich weis noch wie mich jemand fragte damals was man brauch um auf 1024 spielen zu können, und ich sagte es wären ur Gerüchte, so eine Karte gibts nicht, die mehr als 800*600 und mehr als 1024 niemals nötig ist und es noch Jahre dauert bis es soweit ist und er sich mit 640*480 schon sehr erfreuen kann eine der besten GraKa zu haben LOOOL..

TT : Dual-Karten finde ich gut... ich versuche meine zwar wieder zu verkaufen, aber nur Aufgrund der Lautstärke.. Verbrauch ist 2-Rangig bei sowas. Und solange es keine Boardhersrteller gibt, die 4 bis 6 PCIe Steckplätze auf x16 in Planug haben, ist Multi-GPU die einzigste und schnellste Lösung imo.. egal ob Multi oder Single.. die GPUs werden so oder auch anders weiter verbessert.. Irgendwann haben wir ne GraKa mit 16 GPUs drauf und nen PCIe STeckplatz der sich anders nennt und x256 Lanes hat..wird kommen..dauert halt nur noch etwas ;-)

LOL.. ich rede von den frühen 90er späten 80ern. wo du dich \"von\" Schreiben konntest wenn du mehr als 512KB Speicher oder so hattest.. die Geauen Zahlen weis ich nicht mehr..zu lang her... aber es hat mich einige Blitzeinschläge bei der Versicherung gekostet (um immer an die neuste HW dran zu kommen) bis ich endlich mal auf 640 spielen konnte.. das war noch als Voodoo selbst bei PC-Usern lediglich eine Religion war und nichts mit PC zu tun hatte, damals wurde auch noch kein deutsch im Web gesprochen, und wehe du hast auf Platformen mal deustch geredet wurdest du vo deutschen platz gemacht, du sollst dich doch bitte an die Internationale Sprache halten und CompuServe noch WinCIM war oder mal noch über wie hiessen die Dinger \"Mailboxen\" oder sowas einwählen musste, um ein gate zum I-Net zu bekommen
 
Zuletzt bearbeitet von einem Moderator:
um diese dann auf einem Die zu vereinen. Gute Begründung: keine Mikroruckler ;)
SLI damals bzw. der Vorgänger davon war ja richtig effizient...

Neja Microruckler kommen ja nicht durch die beiden GPUs ansich, sondern nur, weil die Bilder nicht in einem gleichmäßigen Abstand rausgegeben werden.
Wenn das ganze nicht irgendwie festgesetzt oder syncronisiert wird, ändert dabei eine Art Dualcore GPU auch nix dran.

Rein logisch gesehen weil eben immernoch 2 GPUs gleichzeitig am gleichen Material arbeiten und die Ausgabe ebenso einer syncronisation bedarf. Fällt letztere weg, ist der Effekt der gleiche.
 
warum soll sich geringer stromverbrauch nicht mit der oberen leistungsliga vereinen lassen?
ich brauch im 2 betreib nicht die leistung von 83292349023480 sp
im grunde sollte es doch möglich sein son grafikmonster wenigstens im 2d betrieb auf totaler sparflamme zu betreiben, und damit meine ich maximal 30watt eher weniger
 
warum soll sich geringer stromverbrauch nicht mit der oberen leistungsliga vereinen lassen?
ich brauch im 2 betreib nicht die leistung von 83292349023480 sp
im grunde sollte es doch möglich sein son grafikmonster wenigstens im 2d betrieb auf totaler sparflamme zu betreiben, und damit meine ich maximal 30watt eher weniger

Technisch ist das sicher möglich, nur frage ich mich manchmal oft, will der Kunde das überhaupt?
Gekauft werden die Karten doch trotzdem, also warum sollte ein Hersteller da hirnschmalz reinstecken!?

Ein guter Ansatz war ja diese Hybrit Boost/SLI Technik von NV, wo angeblich ein deaktivieren der GPU funktionierte im 2D Betrieb, warum und wieso man das nun nicht weiter perfektioniert, kann ich dir nicht sagen...
 
Eine Optimierung des 2D-Verbrauchs wäre wirklich gut, gilt aber nicht nur für Dual-GPU Karten. ;) Das wünschen wir uns doch schon alle längere Zeit. NV gelingt das mit den aktuellen GTX 2xx und der GTS 250 schon recht gut. AMD müsste in diesem Bereich ebenfalls bei den Single-GPU Karten nachbessern. Mal schauen, was uns die nächste Generation bringt.

Hybrid-SLI und -CF waren / sind im Ansatz eine gute Idee - da gebe ich fdsonne recht. Leider hat NV dies aus seinem Programm - zumindest Desktop-Segment, siehe weiter oben bereits aufgelisteten Karten - gestrichen. Mit einer einzelnen Karte funktionierte nach mehreren Userberichten der Energiesparmodus wohl recht gut. Wenn ich mich recht entsinne, funktionierte das bei mehreren Karten jedoch nicht mehr. Bei AMD funktioniert generell nur der Betrieb mit kleineren Karten - egal ob IGP und zusätzliche GPU gemeinsam, oder Energiesparmodus - welche nicht zum Spielen gedacht sind. Da war NV schon weiter.
 
Neja Microruckler kommen ja nicht durch die beiden GPUs ansich, sondern nur, weil die Bilder nicht in einem gleichmäßigen Abstand rausgegeben werden.
Wenn das ganze nicht irgendwie festgesetzt oder syncronisiert wird, ändert dabei eine Art Dualcore GPU auch nix dran.

Rein logisch gesehen weil eben immernoch 2 GPUs gleichzeitig am gleichen Material arbeiten und die Ausgabe ebenso einer syncronisation bedarf. Fällt letztere weg, ist der Effekt der gleiche.

Rein logisch betrachtet gibt es keine Verzögerungen mehr wenn alle "Cores" in einem nativen Design auf dem Die sind. Siehe Larabee, wie soll sich da eine Verzögerung beim Output der Bilder ergeben?
 
Rein logisch betrachtet gibt es keine Verzögerungen mehr wenn alle "Cores" in einem nativen Design auf dem Die sind. Siehe Larabee, wie soll sich da eine Verzögerung beim Output der Bilder ergeben?

Das Problem ist doch eher der Punkt, das die Karten ihr Bild ausgeben, wenn es fertig gerendert wurde, um so mehr Rechenkerne an einer Bildserie arbeiten, desto mehr verschiedene Outputzeiten wirst du haben...
Ohne eine Logik, welche diese Outputzeiten angleicht, geht das ganze imho nicht...
Und dabei ist es egal ob native DC oder nicht, das Problem bleibt weiterhin bestehen, wenn eine Recheneinheit schneller fertig ist mit einem Bild als die andere, dann wirft sie das Bild eher aus, was zu unregelmäßigen Zeitabständen kommt und somit zu MR.
Nachteil beim angleichen der Outputzeiten, die langsamste Recheneinheit bestimmt hier die Musik, heist soviel wie, das die schnelleren Einheiten eben dann warten müssten, was Leistung und schlussendlich FPS kostet...

Man könnte aber alternativ den Threadhandler noch weiter optimieren, weil mir scheint, das dieser die Last nicht exakt genug verteilt auf die GPUs.
Aber das geht wohl im AFR Modus nicht anders, da sich dort die Bilder ja je nach Zustand stark unterscheiden können und somit auch die anfallende Last...

Da beim LRB eigentlich alles auf Software aufbaut und sogut wie nix über die Berechnungsmethode bekannt ist, kann man darüber noch nicht soo viel sagen. Ich gehe aber stark davon aus, das Intel sich da irgendwas via Software Syncronisiert.
Wobei ich denke, Intel wird nen gänzlich anderen Weg als den AFR Modus gehen, wie derzeit idR bei SLI/CF.
Einfach aus den Grund, das beim AFR ja die Bilder im Vorrausberechnet werden, sprich bei 32 Recheneinheiten würde die letzte Einheit schon das zweiundreisigste Bild nach dem jetzigen Ereigniss berechnen. Eine derartige Vorrausberechnung macht das ganze aber akut ineffizient, weil durch Usereingaben zB. vieles über den Haufen gewurfen werden müsste...

Man sieht ja im Moment wie schlecht Quad CF/SLI skaliert...
(Mal ganz davon ab, das im DX9 Modus nur 3 Bilder maximal vorrausberechnet werden können)
 
Richtig ohne AFR gibt es auch keine Microruckler ;)
 
Erstens entstehen keine Mikroruckler weil AFR und co. höchstwahrscheinlich beim Larabee nicht zum tragen kommen werden. Zweitens ist eine Karte mit einem nativen "Multicore" design auch nicht mehr exakt wie eine GPU a lá GT200 aufgebaut, eher CPU-ähnlich. Vllt. habe ich mich nicht richtig ausgedrückt: es ging eher darum, dass man die einzelnen GraKa "Kerne" auf ein Die packen könnte (vllt. in 28nm wenn es möglich ist, um so Platz zu sparen); dann hat man z.B. 2 GPUs die miteinander verschmolzen auf einem Die liegen und so zusammen arbeiten. Erstens ist AFR hinfälllig, zweitens gibt es das Thema Mikroruckler nicht mehr.
 
wenn du 2 chips auf ein die packst, kannst du nicht gleich einen chip nehmen und bei dem einfach die shader/rops/etc verdoppeln? :fresse:
 
Nein, das weiß ich, deswegen steht da auch "mit einander verschmolzen", sprich ein verändertes Design ;)
 
ich kenn mich mit grafikchipdesin nun nicht so aus, weswegen das auch als frage ;)

ich glaub wir reden in einem monat in md nochmal darüber :wink:
 
Erstens entstehen keine Mikroruckler weil AFR und co. höchstwahrscheinlich beim Larabee nicht zum tragen kommen werden. Zweitens ist eine Karte mit einem nativen "Multicore" design auch nicht mehr exakt wie eine GPU a lá GT200 aufgebaut, eher CPU-ähnlich. Vllt. habe ich mich nicht richtig ausgedrückt: es ging eher darum, dass man die einzelnen GraKa "Kerne" auf ein Die packen könnte (vllt. in 28nm wenn es möglich ist, um so Platz zu sparen); dann hat man z.B. 2 GPUs die miteinander verschmolzen auf einem Die liegen und so zusammen arbeiten. Erstens ist AFR hinfälllig, zweitens gibt es das Thema Mikroruckler nicht mehr.

Nein hätte man nicht, auch ein zusammenbringen im gleichen Trägermaterial bringt dir keine möglichkeit, das die beiden Cores sich untereinander unterhalten können, wie auch.
Ist das gleiche wie bei ner Dual CPU Sockel Maschine und nem native Dualcore. Die Anwendung muss der ganzen Sache sagen, wie die Cores genutzt werden. Die Hardwareseitigen Kommunikationswege sind ja nach wie vor schon vorhanden.
Wie du verschiedene Kerne auf die Karten bringst ist vollkommen schnurtz, wenn du zwei einzellne Kerne hast, wirst du eine Technik brauchen damit diese miteinander reden können.
Das ganze könnte man via Software lösen, wie aktuell SLI/CF oder aber via Hardware (was sicher gut Aufwand ist)
Am Ende bleibt aber der Punkt, das es einer Syncronisation der Bildausgabe bedarf, wenn diese nicht statt findet, egal in welcher form, kommt es zu MR.
Wenn diese hingegen angewendet wird, musst du mit FPS Verlust rechnen, weil eben eine gewisse Wartezeit mit einfließt.
Andererseits bleibt die Möglichkeit auf SFR zu setzen oder andere Modi zu verwenden, welche alle GPUs an ein und dem selben Bild arbeiten lassen, dann fallen MR auch flach.

Und nein, auch ein natives Dualcore Design würde dem keinen Abbruch tun. Sobald einer der Cores schneller fertig wird mit seiner Arbeit als der andere, und das Bild danach sofort ausgibt, kommt es zu MR, aufgrund dieser unterschiedlichen Ausgabezeiten.
 
Zuletzt bearbeitet:
@fdsonne: also ich formuleire es nochmal anders ^^
Ich meinte damit, dass man ein einheitliches GPU Design schafft und langsam von den 2 GPUs auf eine "verschmolzene" über geht; sprich, man hat dann ein monolithischen Kern, der viele einzelne Recheneinheiten beinhaltet (diese wiederum sind so ähnlich aufgebaut wie eine derzeitige GPU, bloß auf mini skaliert). Da fällt sicherlich die Synchronisation weg, denn wozu brauchst du die dann noch wenn am Ende nur ein fertiges Bild herauskommt?

Beim Larabee wird man mit Sicherheit auch nicht das Problem der MR haben; da kommt es ledigleich darauf an, wie die Last bei den einzelnen Kernen verteilt wird und wie im Endeffekt dann die gesamt FPS aussehen.
 
@fdsonne: also ich formuleire es nochmal anders ^^
Ich meinte damit, dass man ein einheitliches GPU Design schafft und langsam von den 2 GPUs auf eine "verschmolzene" über geht; sprich, man hat dann ein monolithischen Kern, der viele einzelne Recheneinheiten beinhaltet (diese wiederum sind so ähnlich aufgebaut wie eine derzeitige GPU, bloß auf mini skaliert). Da fällt sicherlich die Synchronisation weg, denn wozu brauchst du die dann noch wenn am Ende nur ein fertiges Bild herauskommt?

Neja Moment, du scheinst da einen kleinen Denkfehler zu haben...
Der Vorteil bei aktuellen Lösungen ist, das du mehr Leistung (mit Einschränkungen) ohne großen Aufwand erreichen kannst, indem du einfach eine weitere GPU auf das PCB bringst.
Es bedarf keiner Neuentwicklung der GPU ansich und du gehst möglichen Fertigungsproblemen bei zu großen DIEs aus dem weg.

Das was du meinst ist im Grunde das gleiche wie wenn man bei ner SingleGPU die Recheneinheiten erhöht, nix anderes.
Es ist und bleibt dann aber ne Single GPU.
Wenn du so willst gibts nämlich genau das was du beschreibst bei NV in Form der ROP Cluster, diese sind wahlweise dimensionierbar, und bestimmen die Anzahl der Recheneinheiten und auch des SI zum Beispiel...

Beim Larabee wird man mit Sicherheit auch nicht das Problem der MR haben; da kommt es ledigleich darauf an, wie die Last bei den einzelnen Kernen verteilt wird und wie im Endeffekt dann die gesamt FPS aussehen.

Die Frage ist welchen Modus Intel beim Aufteilen der Last nimmt, wird AFR eingesetzt, was ich stark bezweifel, dann gibts auch MR, wenn diese nicht durch syncronisieren abgefangen werden.
Wird SFR eingesetzt oder andere Techniken, wo alle GPUs am gleichen Bild arbeiten, dann bestehen von vorn herein keine MR. Weil sowieso gewartet werden muss bis das komplette Bild fertig berechnet wurde...
Aber diese Techniken bedürfen wohl erheblich mehr Verwaltungsaufwand, sieht man ja daran, das nur die wenigsten Games auf SFR und Co. setzen...
AFR scheint da viel einfacher zu sein
 
Ich hätte gerne eine Grafiklösung die nicht oder wirklich erst bei 20fps ruckelt, "einmal mehr und einmal weniger" ist kein Argument.
Nur um nicht betriebsblind zu werden habe ich mir vor kurzem die derzeit stärkste verfügbare Einzelkarte gekauft und eingebaut, der Rest steht in meiner Sig.
 
@fdsonne
Neja Moment, du scheinst da einen kleinen Denkfehler zu haben...
Der Vorteil bei aktuellen Lösungen ist, das du mehr Leistung (mit Einschränkungen) ohne großen Aufwand erreichen kannst, indem du einfach eine weitere GPU auf das PCB bringst.
Es bedarf keiner Neuentwicklung der GPU ansich und du gehst möglichen Fertigungsproblemen bei zu großen DIEs aus dem weg.

Das was du meinst ist im Grunde das gleiche wie wenn man bei ner SingleGPU die Recheneinheiten erhöht, nix anderes.
Es ist und bleibt dann aber ne Single GPU.
Wenn du so willst gibts nämlich genau das was du beschreibst bei NV in Form der ROP Cluster, diese sind wahlweise dimensionierbar, und bestimmen die Anzahl der Recheneinheiten und auch des SI zum Beispiel...
Das ist zwar die allereinfachste und kostengünstigste Variante, aber mit dem Weg den Intel mit Larabee geht, sind viel mehr Möglichkeiten vorhanden, z.B. in Sachen Stromaufnahme bzw. Verringerung dessen. Ich denke da z.B. an das Ausschalten einzelner Kerne, was bei einer GPU nicht so ohne weiteres möglich ist. Auch so etwas wie ein Turbo Modus für einzelne Bereiche wie beim i7 wäre denkbar. Also wie man sieht, bei der herkömmlichen Methode ist auch nicht alles Gold was glänzt.

Wenn ich nun, wie du schreibst, einfach die ROP Cluster Anzahl erhöhe, ist es aber nicht das gleiche als wenn ich beispielsweise einzelne aber viele Cluster nehme und diese an einen Art ringförmigen Bus anbinden würde (so wie ein QPI blos im Ring). Wenn nun eine Steuereinheit in der Mitte dessen sitzt und so lange wartet bis jedes Teil-Bild fertig ist, können einfach keine MR entstehen. Wie auch?

Vielleicht, nein sogar höchstwahrscheinlich wird Intel das Problem der Synchronisation beim Larabee über die Software lösen. Nur ist halt die Frage, wie viel sich dort heraus holen lässt?
 
@fdsonne

Das ist zwar die allereinfachste und kostengünstigste Variante, aber mit dem Weg den Intel mit Larabee geht, sind viel mehr Möglichkeiten vorhanden, z.B. in Sachen Stromaufnahme bzw. Verringerung dessen. Ich denke da z.B. an das Ausschalten einzelner Kerne, was bei einer GPU nicht so ohne weiteres möglich ist. Auch so etwas wie ein Turbo Modus für einzelne Bereiche wie beim i7 wäre denkbar. Also wie man sieht, bei der herkömmlichen Methode ist auch nicht alles Gold was glänzt.
Da hast du natürlich recht, machbar wäre sicher viel, man muss aber dran denken, das die Entwicklungskosten auch wieder rein kommen.
Und gerade in heutigen Zeiten, wo alles einfach nix kosten darf, ist die Sache, wie sie jetzt ist, eigentlich Goldrichtig...
Zumahl es immer verückte geben wird, die sowas kaufen.

Übrigens, nen Turbomodus könnte man ebenso bei heutigen Karten implementieren, ich denke da zum Beispiel an das CCC bei AMD und Overdrive...
Die Frage ist eher, ob das Sinn macht, weil wenn die Cores den höheren Takt mitmachen, warum nicht dann gleich per default eindrehen und überall die Mehrleistung genießen!?
Beim i7 bringt der Turbomodus ja viel, wenn Singlethreaded Anwendungen gefahren werden, weil der Takt ne ganze Ecke hoch geht.
Aber wenn ne Anwendung läuft, welche alle Cores auslastet, bringt Turbo fast nix, da kannst auch händisch OCen und hast gleichen/mehr Erfolg :fresse:

Wenn ich nun, wie du schreibst, einfach die ROP Cluster Anzahl erhöhe, ist es aber nicht das gleiche als wenn ich beispielsweise einzelne aber viele Cluster nehme und diese an einen Art ringförmigen Bus anbinden würde (so wie ein QPI blos im Ring). Wenn nun eine Steuereinheit in der Mitte dessen sitzt und so lange wartet bis jedes Teil-Bild fertig ist, können einfach keine MR entstehen. Wie auch?

Das was du beschreibst wäre eine Möglichkeit diese Frametimes zu syncronisieren, gleiches kann man aber bei aktuellen Lösungen machen, bzw. könnte man.
Problem bei deinem ist aber ebenso, das wenn die Einheiten das Bild berechnet haben, diese warten müssten. Was die ganze Sache verlangsamt.
Ich gehe stark davon aus, das es für AMD und NV ein leichtes wäre, die Bildausgabe zu syncronisieren, eben das die Frametimes passen und nicht schwanken. Aber das kostet FPS und das wollen wohl beide Hersteller nicht, weil ja dadurch die Karten langsamer werden :fresse:
Mehr FPS auf dem Papier zählt wohl hier mehr als gefühlt flüssigeres Arbeiten...

Vielleicht, nein sogar höchstwahrscheinlich wird Intel das Problem der Synchronisation beim Larabee über die Software lösen. Nur ist halt die Frage, wie viel sich dort heraus holen lässt?

Ich denke mal, das wird sich noch zeigen...
Vorteil an der Softwaregeschichte, das lässt sich im Nachhinein noch sehr einfach optimieren...
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh