PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : GraKas mit Dual-Core


Azubi
2005-07-05, 13:13:39
Hi,

ich finde SLI oder Crossfire ja nicht schlecht. Aber ob das wirklich der Weisheit letzter Schluß ist?

2 GraKa's nehmen viel Platz weg. Zusätzlich mehr Lärm mit 2 Lüftern. Unterschiedliche Karten laufen nicht so ohne weiteres miteinander.

Wann kommen den nun endlich die Dual-Cores-Grakas für PCI-e? Laufen auf jedem neueren System. Leistungsmäßig gleich oder wahrscheinlich besser als SLI oder Crossfire. Und endlich mal wieder mehr Platz im Gehäuse.

Ich glaube ja, das SLI und Crossfire wohl ehr Notlösungen sind. Die Zukunft liegt wohl in X-Core's-GraKas. Oder was meint ihr?

Gruß

Azubi

Änderung:
Ich hoffe ja das ATI mit so einer Karte kontern wird :rolleyes:

Lilebror
2005-07-05, 13:28:27
Du hast schon recht vom rein praktischen her wären Graka's mit dualcore schon besser, bedenke aber das ein SLI system sich ausbauen lässt, habe ich zB. imo nich das Gedl für 2 Grafikkarten und diese Leistung ist sowieso überflüssig kaufe ich mir erstmal nur eine, will ich dann aufrüsten kaufe ich mir einfach noch eine hinzu und kann so mein System aufmotzen ohne mir direkt eine einzelne neue Karte zu holen die ich dann an stelle der alten einbaue, so kann man schon vorhandene power mit neuer ergänzen im Fall von Nvidia halt mit einer gleichschnellen und bei ATI später mit einer schnelleren Graka, somit schlägt einem der Wertverlust der alten nicht so auf den Magen, da man die 2 dann ja warscheinlich zu einem günstigeren Preis erstanden hat.

DerRob
2005-07-05, 13:44:33
würde nicht viel bringen. die grafikkarten werden momentan zu einem großteil durch die speicherbandbreite begrenzt. also müssten sich beide cores z.b. eine 256bit speicheranbindung teilen, was natürlich beide cores ziemlich ausbremsen würde. man könnte jetzt natürlich jedem core seine eigenen 256bit zuteilen, aber dann kann man auch gleich nen einzelnen core mit ner 512bit anbindung bauen. beides ist noch nicht günstig genug machbar.

Windi
2005-07-05, 13:47:29
Dual Core wird es auf Grafikkarten nie geben. Höchstens, wie bei Asus, ein SLI-System auf einer Karte (oder halt Crossfire), und die wirds nur in sehr geringen Mengen geben.

Coda
2005-07-05, 13:54:37
Grafikchips haben jetzt schon 24 exakt identische Pixelprozessoren und 8 identische Vertexprozessoren.

Es muss nicht erst gemacht werden, sondern es ist schon lange so.

PatkIllA
2005-07-05, 13:55:28
Eine Grafikkarte ist doch schon von Anfang auf parallele Ausführung getrimmt. Da wird dann halt nur nicht mehr oder weniger der ganze Core kopiert, sondern es wird mit immer mehr Pipelines in die Breite gegangen, wenn der Fertigungsprozess es her gibt.

edit: Coda war schneller.

Winter[Raven]
2005-07-05, 14:01:00
Gab es nicht mal Gerüchte Nvidia wolle in nächster Zukunft Dualcores bringen, im Sinne des geteilten Cores? 2 Chips auf dem PCB, der eine übernimmt aber nur ganz spezielle Aufgaben?

Gast
2005-07-05, 14:05:31
die kühlung wäre sehr viel schwerer als auf einem echten SLI-system zu realisieren.

storms18
2005-07-05, 14:06:53
Ich hab mir das mit dualcore oder 2gpu's auf einem PCB auch schonma vorgestellt.

z.B: Die 1. gpu übernimmt das ganz normale rendern also mit allem drum und dran. Die 2. GPU kümmert sich dann nur um das AA&AF. So könnte man ohne großen performance verlust immer mit max. quali fahren.

PatkIllA
2005-07-05, 14:08:12
Ich hab mir das mit dualcore oder 2gpu's auf einem PCB auch schonma vorgestellt.

z.B: Die 1. gpu übernimmt das ganz normale rendern also mit allem drum und dran. Die 2. GPU kümmert sich dann nur um das AA&AF. So könnte man ohne großen performance verlust immer mit max. quali fahren.
Wie soll das denn gehen? nachher das AF/AA reinrechnen?!?!

Gast
2005-07-05, 14:09:22
z.B: Die 1. gpu übernimmt das ganz normale rendern also mit allem drum und dran. Die 2. GPU kümmert sich dann nur um das AA&AF. So könnte man ohne großen performance verlust immer mit max. quali fahren.

rofl, wie soll den dass funktionieren, AA und AF muss beim rendern gemacht werden, und kann man nicht nebenher in einen anderen chip auslagern :D

storms18
2005-07-05, 14:10:14
Oha wusste ich nicht:D

Neomi
2005-07-05, 14:14:53
Multi-Core ist bei CPUs eigentlich nur dazu da, Multi-CPU-Systeme wirtschaftlicher (Zahl der CPU-Sockel, Boardlayout, ...) umzusetzen. Da es nicht automatisch genutzt werden kann, sondern gezielt genutzt werden muß, hat es eben länger gebraucht und wird erst langsam auch für größere Teile des Marktes interessant.

GPUs dagegen haben ein Aufgabengebiet, welches sich hervorragend parallelisieren läßt. Genau deshalb gibt es das, was du dir hier wünschst, schon längst, nur eben in einer effektiveren Form. Der G70 beispielsweise hat 24 Pixelpipelines (bzw. 6 Pixelquads) und 8 Vertexshader-Einheiten. Weitere Einheiten lassen sich theoretisch in beliebiger Zahl dranhängen. Außerdem ist es transparent für die Anwendung.

Bei GPUs gibt es Parallelisierung im Core, bei CPUs ist es Parallelisierung durch mehrere Cores. Die Parallelisierung im Core ist die bessere Variante, bei CPUs durch das andere Aufgabengebiet aber nicht so einfach machbar.

Edit: holla, eben waren all die Antworten noch nicht da. :D

Kladderadatsch
2005-07-05, 14:21:34
Bei GPUs gibt es Parallelisierung im Core, bei CPUs ist es Parallelisierung durch mehrere Cores. Die Parallelisierung im Core ist die bessere Variante, bei CPUs durch das andere Aufgabengebiet aber nicht so einfach machbar.

ansonsten könnte ein dual-core-prozessor seinen zweiten core effektiv in jeglichen anwendungen ausnutzen, was jetzt nicht der fall ist?

HOT
2005-07-05, 14:34:31
Eine Geforce 6800 besteht aus 11 Cores ;)
6 Vertexprozessoren
4 Pixelprozessoren
1 Videoprozessor

Xmas
2005-07-05, 14:34:58
Weitere Einheiten lassen sich theoretisch in beliebiger Zahl dranhängen.
Aber eben nur theoretisch.

Coda
2005-07-05, 15:24:42
Wieso nur theoretisch? Da sehe ich eigentlich nur physische Limits.

Neomi
2005-07-05, 15:27:50
ansonsten könnte ein dual-core-prozessor seinen zweiten core effektiv in jeglichen anwendungen ausnutzen, was jetzt nicht der fall ist?

Ja, das ist jetzt nicht der Fall. Der zweite Core wird von einem zweiten Thread (per Software kontrolliert) genutzt, nicht vom ersten Core. Ein Core, der Out-of-Order-Execution beherrscht, kann mehrere voneinander unabhängige Befehle parallel ausführen. Je mehr Recheneinheiten er dazu zur Verfügung hat, desto mehr unabhängige Befehle kann er auch gleichzeitig ausführen. Die Recheneinheiten des zweiten Cores stehen ihm aber nicht zur Verfügung, auch wenn diese gerade nichts zu tun haben.

@Xmas:
Ja natürlich, deshalb habe ich ja auch extra "theoretisch" geschrieben.

Neomi
2005-07-05, 15:33:52
Wieso nur theoretisch? Da sehe ich eigentlich nur physische Limits.

Die Einheiten werden doch bestimmt als eine Art Array angesprochen. Wenn der Index, mit dem Pixelquads und Vertexeinheiten angesteuert werden, jetzt nur 4 Bit groß ist... aber das wird wohl kaum zu Lebzeiten der Architektur ein Problem sein. Die physischen Limits werden erstmal alleine für die praktisch machbaren Konfigurationen verantwortlich sein.

Xmas
2005-07-05, 15:52:04
Wieso nur theoretisch? Da sehe ich eigentlich nur physische Limits.
:confused:
Ich auch, und deswegen ist es eben nur theoretisch möglich.

Praktisch rechne ich mit Multi-Die-Lösungen.

reunion
2005-07-05, 15:59:24
Würde sich so eine Multi-Core-Lösung eigendlich genau so verhalten wie ein Single-Core-Chip, oder müsste man diese per SLi - mit den bekannten Nachteilen - verbinden?

Xmas
2005-07-05, 16:18:36
Die Nachteile von SLI entstehen hauptsächlich deswegen weil die Bandbreite zwischen den Chips nicht ausreicht, um alle Daten zu teilen. Bei Dual-Die auf einem Package ist Bandbreite kein Problem. Man sollte die Chips also so designen können dass keine oder kaum Nachteile entstehen.

Coda
2005-07-05, 16:22:21
Praktisch rechne ich mit Multi-Die-Lösungen.Ich nicht.

Zu teuer. Das wird erst passieren wenn keine kleineren Strukturen mehr möglich werden.

Xmas
2005-07-05, 16:42:42
Da du "zu teuer" sagst, weißt du denn wieviel ein Dual-Die-Package mehr kostet?

reunion
2005-07-05, 16:43:19
Die Nachteile von SLI entstehen hauptsächlich deswegen weil die Bandbreite zwischen den Chips nicht ausreicht, um alle Daten zu teilen. Bei Dual-Die auf einem Package ist Bandbreite kein Problem. Man sollte die Chips also so designen können dass keine oder kaum Nachteile entstehen.


Es könnte den Benutzer also praktisch egal sein, ob seine Karte jetzt einen Single- oder einen Dual-Core beinhaltet? - Wenn man es richtig implementiert.

reunion
2005-07-05, 16:44:58
Da du "zu teuer" sagst, weißt du denn wieviel ein Dual-Die-Package mehr kostet?


Könnte man die beiden Dies nicht in einem Package unterbringen, so wie es nV jetzt mit dem NV45 macht?

Xmas
2005-07-05, 16:46:12
Ja davon rede ich doch.

reunion
2005-07-05, 16:47:00
Ja davon rede ich doch.


Was soll dann teurer werden?
Wäre doch egal, ob man ein großes, oder zwei halb so kleine Dies dort platziert.

Gast
2005-07-05, 17:08:49
Was soll dann teurer werden?
Wäre doch egal, ob man ein großes, oder zwei halb so kleine Dies dort platziert.
Das weiß nur Coda. Im Endeffekt arbeiten ATI und nVida an Dualcore GPUs. Im Revolution soll angeblich ein Dulacore R520 zu finden sein.

Xmas
2005-07-05, 17:55:47
Was soll dann teurer werden?
Wäre doch egal, ob man ein großes, oder zwei halb so kleine Dies dort platziert.
Nicht ganz. Das Package wird teurer weil es mehr Leitungen benötigt, außerdem ist auch das Aufbringen von zwei Dice etwas teurer.
Dazu kommt, dass man wohl identische Dice mit somit redundanten Teilen baut und auch für die Inter-Die-Kommunikation Transistoren aufwenden muss. Das muss man natürlich durch höheren Yield erst mal wieder rausholen. Gleichzeitig spart man allerdings auch die Entwicklung eines Mainstream-Chips. Dafür nimmt man einfach einzelne Dies.