> > > > AMD: Weitere Dual-GPU-Karten geplant

AMD: Weitere Dual-GPU-Karten geplant

Veröffentlicht am: von

amdDank der Verwendung zweier Grafikprozessoren auf nur einem Printed-Circuit-Board (PCB), gelang es AMD 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 Preisvergleich derzeit ab etwa 324 Euro zu haben ist, die Performancekorne in die eigenen Reihen. Doch damit soll noch lange nicht Schluss sein. Wie die stets gut bediente Gerüchteküche Fudzilla.com heute berichtete, wird die Reihe auch mit dem RV870 weiter fortgeführt. So soll die kommende Dual-GPU-Grafikkarte mit dem Codename R800 auf zwei RV870-Chips, welche bereits im 40-nm-Fertigungsverfahren gefertigt werden sollen, daherkommen und bereits Unterstützung für DirectX 11 mit sich bringen. Das neue Flaggschiff soll noch in diesem Jahr offiziell das Licht der Welt erblicken und gegen den GT300, welcher in etwa zur gleichen Zeit erscheinen wird, antreten. Wie immer hält sich der US-Amerikanische Grafikchipentwickler sehr bedeckt, was seine kommenden Produkte betrifft und bestätigte diese Informationen somit natürlich noch nicht.

 

Weiterführende Links:

Social Links

Ihre Bewertung

Ø Bewertungen: 0

Tags

es liegen noch keine Tags vor.

Kommentare (34)

#25
customavatars/avatar17222_1.gif
Registriert seit: 02.01.2005
in deinem PC
Moderator
[online]-Redakteur
Kontrolletti vom Dienst
Beiträge: 9754
@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.
#26
customavatars/avatar44491_1.gif
Registriert seit: 08.08.2006
SN
Moderator
Beiträge: 33007
Zitat PCZeus;12121187
@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...

Zitat PCZeus;12121187
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
#27
Registriert seit: 21.06.2008

Oberbootsmann
Beiträge: 925
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.
#28
customavatars/avatar17222_1.gif
Registriert seit: 02.01.2005
in deinem PC
Moderator
[online]-Redakteur
Kontrolletti vom Dienst
Beiträge: 9754
@fdsonne
Zitat

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?
#29
customavatars/avatar44491_1.gif
Registriert seit: 08.08.2006
SN
Moderator
Beiträge: 33007
Zitat PCZeus;12129112
@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:

Zitat PCZeus;12129112

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...

Zitat PCZeus;12129112
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...
#30
customavatars/avatar17222_1.gif
Registriert seit: 02.01.2005
in deinem PC
Moderator
[online]-Redakteur
Kontrolletti vom Dienst
Beiträge: 9754
Zitat fdsonne;12129319
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:



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...




Ich denke mal, das wird sich noch zeigen...
Vorteil an der Softwaregeschichte, das lässt sich im Nachhinein noch sehr einfach optimieren...


Jein, umso mehr Einheiten man implementiert, desto geringer wird die Wartezeit die verbracht werden muss bis das komplette Bild fertig gerendert ist ;)
#31
customavatars/avatar44491_1.gif
Registriert seit: 08.08.2006
SN
Moderator
Beiträge: 33007
Zitat PCZeus;12132751
Jein, umso mehr Einheiten man implementiert, desto geringer wird die Wartezeit die verbracht werden muss bis das komplette Bild fertig gerendert ist ;)


Das würde ich mal nicht sagen, denn die Einheiten arbeiten nicht am selben Bild, auch wenn du 4 oder 8 GPUs hättest, die Frametimes unterscheiden sich.
Und dabei ist die Anzahl der GPUs recht egal, weil die Bilder ja im Vorraus berechnet werden.
Eigentlich sogar noch schlimmer, wenn mehr GPUs mitrechnen, müssten mehr GPUs auf die langsamste Einheit warten, sprich mit jeder neuen GPU wird mehr Wartezeit entstehen. Was die ganze Sache neben dem Vorrausberechnen der Bilder nochmals ineffizienter macht.

Ich denke mal für den Endkunden ist so eine Syncronisierung der Frametimes keine Lösung, viel mehr könnten andere Rendermodi abhilfe schaffen. Wie gesagt bei SFR gibts keine MR mehr, weil alle GPUs am gleichen Bild arbeiten...
#32
customavatars/avatar17222_1.gif
Registriert seit: 02.01.2005
in deinem PC
Moderator
[online]-Redakteur
Kontrolletti vom Dienst
Beiträge: 9754
Zitat fdsonne;12133811
Das würde ich mal nicht sagen, denn die Einheiten arbeiten nicht am selben Bild, auch wenn du 4 oder 8 GPUs hättest, die Frametimes unterscheiden sich.
Und dabei ist die Anzahl der GPUs recht egal, weil die Bilder ja im Vorraus berechnet werden.
Eigentlich sogar noch schlimmer, wenn mehr GPUs mitrechnen, müssten mehr GPUs auf die langsamste Einheit warten, sprich mit jeder neuen GPU wird mehr Wartezeit entstehen. Was die ganze Sache neben dem Vorrausberechnen der Bilder nochmals ineffizienter macht.

Ich denke mal für den Endkunden ist so eine Syncronisierung der Frametimes keine Lösung, viel mehr könnten andere Rendermodi abhilfe schaffen. Wie gesagt bei SFR gibts keine MR mehr, weil alle GPUs am gleichen Bild arbeiten...


kleines Mißverständnis ;) siehe Posts weiter oben, ich ging davon aus, dass man viele kleine Einheiten nimmt und diese in einer ringförmigen Anordnung um einen Logik- bzw. Steuerchip anordnet; wenn man also mehr Einheiten um diesen zentralen Chip anordnet und diese nun alle einen kleinen Teil vom Bild berechnen, dann wird jede kleine Einheit schneller fertig werden mit seiner Teilaufgabe als wenn man nur 2 oder 3 Einheiten nimmt. ;) Das meinte ich damit. Erst wenn jede Einheit mit ihrem Teil fertig ist, wird das Bild zum Steuerchip in der Mitte und dann zum Ausgang geschickt. (Die Steuereinheit kann ja mit den anderen Einheiten auf einem Die liegen; räumliche Trennung auf dem PCB ist ja nicht von Nöten).
#33
customavatars/avatar44491_1.gif
Registriert seit: 08.08.2006
SN
Moderator
Beiträge: 33007
Zitat PCZeus;12134939
kleines Mißverständnis ;) siehe Posts weiter oben, ich ging davon aus, dass man viele kleine Einheiten nimmt und diese in einer ringförmigen Anordnung um einen Logik- bzw. Steuerchip anordnet; wenn man also mehr Einheiten um diesen zentralen Chip anordnet und diese nun alle einen kleinen Teil vom Bild berechnen, dann wird jede kleine Einheit schneller fertig werden mit seiner Teilaufgabe als wenn man nur 2 oder 3 Einheiten nimmt. ;) Das meinte ich damit. Erst wenn jede Einheit mit ihrem Teil fertig ist, wird das Bild zum Steuerchip in der Mitte und dann zum Ausgang geschickt. (Die Steuereinheit kann ja mit den anderen Einheiten auf einem Die liegen; räumliche Trennung auf dem PCB ist ja nicht von Nöten).


Wie schon gesagt, das ändert nix an der Tatsache, da das ganze schlussendlich vom Rendermodi abhängt.
Du schriebst, wenn alle einen kleinen Teil vom Bild berechnen...
Das entspricht SFR oder anderen Rendermodi, wo alle am GPUs am gleichen Frame arbeiten, hier gibts auch keine MR... ;)
Es wird aber aktuell meist mit AFR gearbeitet, sprich Bilder werden im Vorrausberechnet und somit würde auch jede Komponente in deinem Ringsystem ein eigenes komplettes Bild berechnen, ist eine GPU fertig gibts sie es aus, und genau das kommt zu den unstimmigen Frametimes. Eine Syncronisierung dieser Frametimes hingegen würde die Einheiten zum warten zwingen, was Leistung kostet.
Das könnte zum Beispiel ein Grund sein, warum SFR nicht gern genommen wird, weil eine der beiden Einheiten in ner Dual GPU Geschichte idR immer eher fertig ist und warten müsste, bei AFR hingegen kann sie sofort mit dem nächsten Bild weiter machen.
#34
customavatars/avatar17222_1.gif
Registriert seit: 02.01.2005
in deinem PC
Moderator
[online]-Redakteur
Kontrolletti vom Dienst
Beiträge: 9754
Also liege ich da gar nicht so falsch, wenn ich behaupte, dass es mit meiner Mehtode keine MR mehr gibt, es aber wesentlich mehr Leistung kostet?
Vllt. ist es für nVidia und co. einfacher AFR im Treiber zu implementieren als andere Rendermodi :rolleyes: Vor allem der Verwaltungsaufwand bei SFR (das muss ja nicht bei einer Hälfte des Bildes bleiben).
Daher wundert es mich schon ein bisschen, warum die Hersteller noch nicht den Weg gegangen sind, den ich weiter oben beschrieben habe (alle Einheiten sind ringförmig angeordnet und berechnen entsprechend der Einheitenanzahl ein Bruchstück des Gesamtbildes). Denn umso mehr Einheiten ich habe, desto schneller werde ich im Endeffekt doch fertig?
Um Kommentare schreiben zu können, musst Du eingeloggt sein!

Das könnte Sie auch interessieren:

Von ASUS bis ZOTAC: Vier Modelle der GeForce GTX 1050 Ti im Test

Logo von IMAGES/STORIES/GALLERIES/REVIEWS/2016/NVIDIA-GTX1050TI-ROUNDUP/NVIDIA_GTX1050TI_4ER_ROUND_UP-TEASER

Seit Ende Oktober gibt es die aktuelle Pascal-Generation von NVIDIA auch für unter 200 Euro. Tatsächlich bekommt man hier nicht nur viel Leistung fürs Geld, sondern obendrein einen sehr effizienten 3D-Beschleuniger, wie unser Launch-Test zur NVIDIA GeForce GTX 1050 Ti pünktlich zum Marktstart... [mehr]

AMD Radeon RX Vega 56 und Vega 64 im Undervolting-Test

Logo von IMAGES/STORIES/2017/AMD_RADEON_RX_VEGA_64_56_TEST

Unser Test der Radeon RX Vega 64 und Vega 56 hat gezeigt: AMD liefert eine Leistung auf dem Niveau der GeForce GTX 1080 und GeForce GTX 1070, erkauft wird dies aber mit einer deutlich zu hohen Leistungsaufnahme. Derzeit hat AMD bei den Vega-Karten noch viele Baustellen, die vor allem den Treiber... [mehr]

Zwei Modelle der NVIDIA GeForce GTX 1050 Ti im Test

Logo von IMAGES/STORIES/GALLERIES/REVIEWS/2016/EVGA-GTX-1050TI-SC/EVGA_ZOTAC_GTX1050TI_AUFMACHER

Am vergangenen Dienstag rundete NVIDIA sein Pascal-Aufgebot nach unten hin ab und kündigte mit der GeForce GTX 1050 Ti und GeForce GTX 1050 die bislang kleinsten Ableger unter den Pascal-Grafikkarten an. Ab heute werden die neuen Einsteiger-Karten zu Preisen ab 125 bzw. 155 Euro im Handel... [mehr]

MSI GeForce GTX 1060 Gaming X im Test

Logo von IMAGES/STORIES/GALLERIES/REVIEWS/2016/MSI-GTX-1060-GAMING-X/MSI_GEFROCE_GTX_1060_GAMING_X-TEASER

Ob von ASUS, EVGA, Inno3D oder Gigabyte – von nahezu allen großen Grafikkarten-Herstellern konnten wir bereits ein oder mehrere Modelle auf Basis der GeForce GTX 1060 testen. Gefehlt in unserer Liste hat allerdings noch MSI. Das holen wir nun mit einem Test zur MSI GeForce GTX 1060 Gaming X... [mehr]

AMD Radeon RX Vega 64 und RX Vega 56 im Test

Logo von IMAGES/STORIES/2017/AMD_RADEON_RX_VEGA_64_56_TEST

Nun endlich ist es soweit: Was vor gut einem Jahr mit einer ersten Ankündigung begann und ab Ende 2016 konkret wurde, findet nun sein finales Ende in den ersten Tests der Radeon RX Vega 64 und RX Vega 56. AMD ist als einziger Konkurrent zu NVIDIA geradezu zum Erfolg verdonnert. Die Ansprüche an... [mehr]

Ab Werk die schnellste: ZOTAC GeForce GTX 1080 Ti AMP! Extreme Edition im Test

Logo von IMAGES/STORIES/LOGOS-2017/ZOTAC-GTX1080TI-EXTREME-LOGO

Einige Modelle der GeForce GTX 1080 Ti konnten wir uns ja bereits anschauen und damit lässt sich auch ein erster Eindruck zusammenfassen: Die GeForce GTX 1080 Ti ist in der Founders Edition eine gute Karte, die Custom-Modelle beschleunigen sie noch etwas und bieten zudem eine bessere und leisere... [mehr]