[Sammelthread] Grafikkarten - Technikdiskussion

Moment langsam, was passiert wenn man bei der X2 den CF Modus deaktiviert, geht ja über AI Off soweit mir bekannt.

Bei zwei Einzellkarten hätten dann beide GPUs jeweils 1GB und das muss die X2 ebenso haben. Sprich ohne aktives CF hätte jede GPU ihren eigenen Speicher unabhängig vom anderen.
Wie soll das realisiert werden, wenn die von vorneherein alle Daten immer an beide GPUs geschickt werden?

Das mit der Kommunikation über PCIe war wohl etwas schwammig von mir ausgedrückt, ich meinte nicht den PCIe Slot, sondern die PCIe Schnittstelle der GPU. Die GPUs reden über die CF Bridge (die Verbindung oben auf deinem Bild) und zusätzlich über PCIe (bei der X2 aber nicht über den Umweg Slot->Chipsatz und von dort über den anderen Slot zur zweiten GPU sondern direkt intern über den Brückenchip)
;)
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
.

Das die X2 nur 1GB Nutzbar hat, resultiert ja daher, das eben AFR als Modus in 95-99% aller Fälle benutzt wird. Aber und das ist der Punkt, was passiert wenn man bei der X2 den CF Modus deaktiviert, geht ja über AI Off soweit mir bekannt.

Bei zwei Einzellkarten hätten dann beide GPUs jeweils 1GB und das muss die X2 ebenso haben. Sprich ohne aktives CF hätte jede GPU ihren eigenen Speicher unabhängig vom anderen.
Wie soll das realisiert werden, wenn die von vorneherein alle Daten immer an beide GPUs geschickt werden?

Das ist wohl richtig, aber 2 einzelne Karten haben ja auch keine Brückenchip welcher die Daten aufteilt ;) Darum sind das 2 Unterschiedliche Szenarien. Auch wenn du Crossfire deaktivierst, was ja bei der X2 nie richtig funktioniert übrigens hat jede Karte immer noch die gleichen Daten und die 2 CPU liegt brach. Und auch wenn du einen anderen Modus als AFR nutzen würdest brauchen beide CPUs immer noch die gleichen Daten, nur berechnet die jede GPU dann nur ein Teil vom Bild aber die Ausgangdaten das Bild selber ist ja das gleiche.
 
Mhhh
klingt ja erstmal logisch, aber überzeugt mich ehrlich gesagt noch nicht so recht...
Verdammt, ich brauch ne X2 um das nachzutesten. :fresse:


Was passiert eigentlich wenn man CF deaktiviert und dann nen Monitor an die Anschlüsse der zweiten GPU klemmt? Müsste gehen oder?
 
Es würde mich wundern wenn es überhaupt möglich ist einen anderen Modus als AFR zu nutzen, da dieser afaik eigentlich im Treiber integriert ist.

Wenn du jeweils die Chips mit verschiedenen Daten fütterst ist es logisch das sie sich die Bandbreite teilen müssen, aber das ist ein Szenario was wohl kaum ein User nutzt.
 
Es würde mich wundern wenn es überhaupt möglich ist einen anderen Modus als AFR zu nutzen, da dieser afaik eigentlich im Treiber integriert ist.

Wenn du jeweils die Chips mit verschiedenen Daten fütterst ist es logisch das sie sich die Bandbreite teilen müssen, aber das ist ein Szenario was wohl kaum ein User nutzt.

Es ging doch nur ums Prinzip. Wenn die Daten jeweils immer und in jeder Situation gleich an beide GPUs gelangen würden, würden im dem Fall eigentlich teils ungenutzte Daten übertragen werden müssen.

Und welcher Modus am Ende genommen wird bestimmt das interne Treiberprofil für die Games, in den meisten Fällen ist das zwar AFR, aber es gibt sicher auch Außnahmen, nur kann man ja bei AMD nicht wirklich selbst bestimmen...
 
Naja, einen anderen Modus als AFR der genutzt wird ist mir nicht bekannt, da AFR der schnellste Modi ist.

Außerdem sollten wie ja auch bei Fällen bleiben die in der Realität eintreffen, und nicht extra produziert werden um den besagten Fall zu produzieren aber sonst nicht genutzt werden. Bei dem Betrieb von zwei Monitoren solle sich die Bandbreite halbieren, sofern sie verschiedene Dinge darstellen und eigenen Daten brauchen.
 
Ändert aber nix an der Tatsache des verstehens...
Ob das nun in der Realität oft eintritt oder nicht sei erstmal dahin gestellt, es ging um das Technisch machbare bzw. dessen Verständniss, nicht mehr und nicht weniger.

Ist ja jetzt auch egal ;)
Wenn ich mal ne X2 in die Finger bekomm, werd ich das mal durchtesten...
 
Ich bräuchte mal dringend eine Info über gewisse Chips, was es für welche sind und ob die dringend Gekühlt werden müssen oder ob es Passiv reicht zwecks einem Kühler wechsel.

Hier mal ein Bild wo ich die fraglichen Chips ROT eingekreist habe, es handelt sich um eine GeForce 8800 GTS G92.

 
Zuletzt bearbeitet:
Ich würde sagen, wende dich mal freundlich an citizen_one, der kann dir da bestimmt weiterhelfen ;) Schaut hier aber wohl nicht so oft rein, hier sind eher die Theoretiker. :d
 
Ah danke für den Hinweis.
 
hier sind eher die Theoretiker. :d

Da hast du wohl Recht, ich bin wohl mehr Praxisorientiert... :fresse:

Trotzdem recht interessant, die Diskussion hier. :)

____________________________________________________

fdsonne schrieb:
Wenn die Daten jeweils immer und in jeder Situation gleich an beide GPUs gelangen würden, würden im dem Fall eigentlich teils ungenutzte Daten übertragen werden müssen.

Stimmt, so sieht es ja leider in der Praxis auch aus. Es gab mal irgendwo nen Test, wo der Unterschied zwischen 8 und 16 Lanes getestet wurde und da wurde teilweise ein siginifikanter Unterschied festgestellt. Da die 4870 X2 von diesem Problem aber definitiv nicht betroffen ist, spricht eigentlich alles für das (ich nenne es mal... :p) "Le-Frog-Modell". Die Daten kommen über den PCIe-Bus an, werden vom Bridgechip quasi dupliziert und dann an beide Karten übergeben.

Spinnt man den Gedanken weiter, wirds interessanter. Da ja wie fdsonne schon sagte in dem Chip augenscheinlich keine Logik vorhanden ist, um die Daten intelligent zu verteilen, hat die normale 4870 X2 zwei DVI Ausgänge (GPU1) und GPU2 liegt im non-CF Modus einfach brach (freut sich munter über Daten, mit denen sie einfach nichts macht). Schauen wir etwas über den Tellerrand hinaus: Die Sapphire 4850X2 hat 4 DVI Ausgänge, kann 4 Monitore ansteuern (die auch was unterschiedliches anzeigen) und setzt auf ein- und denselben Bridgechip wie auch das 4870 X2 Referenzmodell von AMD. Man müsste jetzt also einfach mal ne X2 nehmen, passend einen Monitor an GPU1 und einen an GPU2 hängen und dann im non-CF Mode nachprüfen, ob der Vram Verbrauch des jeweils anderen nicht genuzten GPUs ebenfalls exorbitant in die Höhe schnellt. Gute Idee, find ich. Das mach ich morgen! :asthanos:

Abgesehen davon fällt mir da noch was anderes ein... Dass der Bridgechip "blöd" ist, ist ja klar, aber meine 2. Karte, die nur den 3. Monitor ansteuert, bekommt ja beim Spielen auch nicht dieselben Daten wie meine Primärkarte. Das würde ja alleine von der Menge des Vrams gar nicht gehen. :fresse: Sprich, bei zwei einzelnen Karten ist sehr wohl ein sinnvolles Verteilen der Daten möglich. Warum macht man das in diesem Falle nicht? So gigantisch kann der Rechenaufwand doch nicht sein, die CPU muss ja eigentlich nix weiter machen, als immer zwischen Rohr 1 und Rohr 2 umzuschalten... :fresse::stupid:
 
@ citizen_one
ich habe mal das Bild in Post # 128 geändert zwecks dem Chip.
 
Warum macht man das in diesem Falle nicht? So gigantisch kann der Rechenaufwand doch nicht sein, die CPU muss ja eigentlich nix weiter machen, als immer zwischen Rohr 1 und Rohr 2 umzuschalten...

Die Frage ist ob das überhaupt möglich ist. Der PCIe anschluss bekommt ja die Daten die für die Ausgabe erforderlich sind. Ich glaube nicht das die Lanes des Slots die Daten die sie verschicken unterscheiden können, das sie ja im Prinzip einfach nur zusammengefasst sind. Also muss die Karte die Daten unterscheiden, was aber wieder ein ziemlicher Aufwand wäre.

Also sollte die 4870 X2, selbst wenn sie unterschiedliche Dinge ausgibt, alles im VRam haben.

Anders sieht es dann wohl nur bei der Nutzung von zwei Karten und damit auch zwei Slots aus.
 
Spinnt man den Gedanken weiter, wirds interessanter. Da ja wie fdsonne schon sagte in dem Chip augenscheinlich keine Logik vorhanden ist, um die Daten intelligent zu verteilen, hat die normale 4870 X2 zwei DVI Ausgänge (GPU1) und GPU2 liegt im non-CF Modus einfach brach (freut sich munter über Daten, mit denen sie einfach nichts macht). Schauen wir etwas über den Tellerrand hinaus: Die Sapphire 4850X2 hat 4 DVI Ausgänge, kann 4 Monitore ansteuern (die auch was unterschiedliches anzeigen) und setzt auf ein- und denselben Bridgechip wie auch das 4870 X2 Referenzmodell von AMD. Man müsste jetzt also einfach mal ne X2 nehmen, passend einen Monitor an GPU1 und einen an GPU2 hängen und dann im non-CF Mode nachprüfen, ob der Vram Verbrauch des jeweils anderen nicht genuzten GPUs ebenfalls exorbitant in die Höhe schnellt. Gute Idee, find ich. Das mach ich morgen! :asthanos:

Abgesehen davon fällt mir da noch was anderes ein... Dass der Bridgechip "blöd" ist, ist ja klar, aber meine 2. Karte, die nur den 3. Monitor ansteuert, bekommt ja beim Spielen auch nicht dieselben Daten wie meine Primärkarte. Das würde ja alleine von der Menge des Vrams gar nicht gehen. :fresse: Sprich, bei zwei einzelnen Karten ist sehr wohl ein sinnvolles Verteilen der Daten möglich. Warum macht man das in diesem Falle nicht? So gigantisch kann der Rechenaufwand doch nicht sein, die CPU muss ja eigentlich nix weiter machen, als immer zwischen Rohr 1 und Rohr 2 umzuschalten... :fresse::stupid:

Auch wenn die Diskusion schon ganz paar Tage auf dem Buckel hat...
citizen, mich würde dennoch deine Erkenntniss interessieren? Hast das mal probiert mit dem Nachmessen des VRams?

Hab zwar nun leihweise auch ne X2, aber mit nur 2 Ausgängen, die beide wohl an einer GPU klemmen.

Interessant zu wissen wäre zum Beispiel auch, was passiert wenn man an diesen beiden Monitoren klemmend an unterschiedlichen GPUs im non CF Modus je eine 3D Anwendung im Fenstermodus startet... Theoretisch müsste dann jeder GPU der eigene Speicher unabhängig von der anderen zur Verfügung stehen, wie sieht das Praktisch aus? (also so ists zumindest bei 2 Einzellkarten)
Wenn das pratisch ebenso ist auf der X2, dann muss der Brückenchip ja dennoch irgend ne Logik haben, oder die GPUs können entscheiden/auswerten, welche Daten der "einkommenden" für sie sind, und welche nicht...
 
Da haben sich leider nicht so knallige Ergebnisse ergeben, da mit Windows Vista das Auslesen der Speicherauslastung leider einfach nicht funktioniert... :shake: Dann war ich noch mit lernen beschäftigt und im Urlaub war ich auch noch und zack, ist der ganze Kram ein bisschen eingefroren... :fresse:

Interessant bleibt das Thema trotzdem, wenn ich nachher neben meiner Präsi über Kernfusion noch bisschen Zeit hab, dann installier ich vlt. mal ein XP und probiere mal etwas rum. Lässt sich vielleicht ganz gut verknüpfen, die Abwärme von ATI Grafikkarten hat ja in den meisten Fällen fast Plasmatemperatur... :fresse: :shot:


Um noch kurz zu deinem zweiten Problem zu kommen... Leider ist es im non-CF (bzw. im non-SLI Mode ebenfalls) so, dass immer die primäre Grafikkarte die 3D Berechnungen übernimmt. Das hab ich schon mal mit ner Permedia 2 PCI Karte (8Mb - DirectX6 Unterstützung :fresse:) ausprobiert. Zweiten Monitor per VGA an die Karte anschließen und dann Crysis im Fenstermodus starten und das Fenster rüberziehen. Ruckelt wie Sau (Limitierung durch die PCI Bandbreite), aber das beweist ja, dass die primäre Karte trotzdem die Berechnungen übernehmen muss, weil die sekundäre technisch ja gar nicht dazu in der Lage ist. ;) Komplizierte Angelegenheit mit diesen Kärtchen... :d
 
Achso, gut nur kein Stress...
Wenn du aber fundierte Ergebnisse liefern kannst, wäre ich dir sehr dankbar...


Zu dem anderen, meinst du wirklich? Die PCI GPU soll dann nur für die sture Ausgabe sein?
Kann ich mir bald gar nicht vorstellen irgendwie!?
Wäre mal interessant zu erfahren, was dann dort mit der GPU Auslastung ist...
Sprich, diese müsste ja dann bei der primären Karte steigen, obwohl die Ausgabe auf der anderen Karte getätigt wird...

Und ja, in Vista kannst die VRam Auslastung leider nicht auslesen, das geht imho nur in 2003 Server und alles was vorher kam... Ab Vista nicht mehr :(
 
]
Ich bräuchte mal dringend eine Info über gewisse Chips, was es für welche sind und ob die dringend Gekühlt werden müssen oder ob es Passiv reicht zwecks einem Kühler wechsel.

Hier mal ein Bild wo ich die fraglichen Chips ROT eingekreist habe, es handelt sich um eine GeForce 8800 GTS G92.


Ich weiss nicht ob es citizen one schon beantwortet hat deine frage,aber falls nicht

Die oben auf deinem bild 3 rot markierten sind Spannungswandler und der einzelne ist irgend ein altea spannungschip (ähnlich dem volterra der 280er karten) u in jedemfall müssen alle 4 chips mitgekühlt werden.

aaaaijss.png


Ich hoffe es ist noch nicht zu spät u du hast die kernschmelze noch nicht ausgelößt:coolblue:

Aber warum stellst du die frage eigentlich nicht im sammelthread?
 
Zuletzt bearbeitet:
@ scully1234

Danke für die Info aber das hatte sich schon für mich erledigt, es ging darum, weil ich ein Review über einen Kühler geschrieben hatte aber meine Karte war nicht Kompatibel mit dem Kühler und daher musste ich Leihweise eine ATI nehmen.

Welchen Sammelthread meinst du eigentlich, den für die Geforce G92?
 
Jungs, ich hab gestern abend vorm Einschlafen über etwas nachgedacht, was ich nicht so recht beantworten konnte.

Und zwar geht es um die in aktuellen GPU-ALUs enthaltene MUL-Funktionalität. Soweit wir wissen, wird dort eine Multiplikation in einem Takt durchgeführt. Die einzige mir bekannte Möglichkeit, die Multiplikation soweit zu parallelisieren, dass das möglich ist, ist per PLA-Decoder-Multiplikationseinheit. Das erfordert aber für 2 32 Bit breite Datenworte schon 2^64 * 64 Bit Speicher und das haben aktuelle ALUs definitiv nicht. Die normale bitserielle Multiplikationslogik braucht pro Stelle des Multiplikanden einen Takt plus einen Takt für die Addition der temporären Ergebnisse - das kann es also auch nicht sein. Aber sogar, wenn man das ähnlich wie beim Carry-Save-Addierer mit großem Logikaufwand zu parallelisieren versucht, sehe ich noch nicht, wie man ohne MIMD-ALUs die gesamte Multiplikation in einen Takt kriegen soll - ich komme bestenfalls auf einen Takt für den multiplikativen Anteil und (je nach ADD-Logik) entsprechend viel für den Rest. Einfach jedes alternative Verfahren, ob auf 2K-Zahlen (wo mir übrigens mal einer sagen könnte, ob Booth Recoding das effizienteste aktuell genutzte Verfahren ist) oder Gleitkommaarithmetik, dauert mehr als einen Takt.

Jemand Ahnung, wie das laufen soll?
 
Zuletzt bearbeitet:
Soweit wir wissen, wird dort eine Multiplikation in einem Takt durchgeführt
Bin mir nicht sicher aber ist es nicht so ,das bei den heutigen SIMD modellen,die berechnung 2mal durch die alus gejagt wird und sich das ganze erst bei MIMD auf einen takt reduziert:confused:
 
Zuletzt bearbeitet:
Die Arithmetikspezifikation aktueller Shaderarchitekturen wird berechnet, indem man die Anzahl der Shader mit der Anzahl der Instruktionen pro Takt mit der Anzahl der Takte multipliziert und ein MUL ist da wohl eine Instruktion pro Takt. Was ich mir vorstellen kann, ist, dass das garnicht wirklich so ist, sondern dass statt 1 MUL/clk eben zB 4 MUL / 4 clk fertiggestellt werden. Das ist aber nur eine Theorie.
 
Die Arithmetikspezifikation aktueller Shaderarchitekturen wird berechnet, indem man die Anzahl der Shader mit der Anzahl der Instruktionen pro Takt mit der Anzahl der Takte multipliziert und ein MUL ist da wohl eine Instruktion pro Takt. Was ich mir vorstellen kann, ist, dass das garnicht wirklich so ist, sondern dass statt 1 MUL/clk eben zB 4 MUL / 4 clk fertiggestellt werden. Das ist aber nur eine Theorie.

Wir bräuchten wohl mal einen techniker der beiden grafikschmieden hier im forum,der könnte das rätzel wohl aufklären:d

Ich weiss nicht mehr wo ich das mit den 2taktzyklen bei SIMD gelesen habe ,ich glaub das war irgendwo im nvidia cuda forum:confused:
 
Für eine einfache Multiplikation? Sicher? Wenn du den Link finden könntest, wär prima.
 
Für eine einfache Multiplikation? Sicher? Wenn du den Link finden könntest, wär prima.

Ich schau mal nach war schon ne weile her vielleicht find ichs ja:p

Edit

Schonmal was gefunden zu SIMD aber das war noch nicht das was ich wollte:confused:

http://forums.nvidia.com/index.php?showtopic=93655

Edit Edit:
unbenanntzstp.png


Das hört sich doch nach mehreren taktzyklen an für die berechnung,oder denk ich jetzt verkehrt wenn ich von SIMD alus ausgehe?
 
Zuletzt bearbeitet:
Ich mach mal ganz dreister weise nen Themenwechseln ;P

Und zwar zum VRam.
Mir stellt sich die Frage warum bei Multichip Lösungen seit jeher jeder Chip seinen eigenen VRam zur seite gestellt bekommt auch wenn sich in beiden Speichern bei modernen Techniken so gut wie die selben Daten befinden. Bei einem Sli oder Crossfire aus mehreren Karten kann ich es nachvollziehen, bei Lösungen auf einem PCB dagegen nicht. Ich steigere als Hersteller ja sogar noch die Kosten.
 
Ich mach mal ganz dreister weise nen Themenwechseln ;P

Und zwar zum VRam.
Mir stellt sich die Frage warum bei Multichip Lösungen seit jeher jeder Chip seinen eigenen VRam zur seite gestellt bekommt auch wenn sich in beiden Speichern bei modernen Techniken so gut wie die selben Daten befinden. Bei einem Sli oder Crossfire aus mehreren Karten kann ich es nachvollziehen, bei Lösungen auf einem PCB dagegen nicht. Ich steigere als Hersteller ja sogar noch die Kosten.

Ganz einfache Sache...
Wie willst du vernünftig eine einzige gemeinsam genutzte Speicheranbindung schaffen?
So eine Logik zu schaffen wäre ja vllt nicht das Problem, sondern eher die Anbindung der GPUs an diese Logik, bedenke, die Speicherbandbreite ist derart hoch, das ein Auslagern der Speicher in eine gemeinsam genutzte Einheit die Verbindung von der Einheit zur jeweiligen GPU extrem schnells ein müsste...
Sowas hast du idR nicht, wird auch schwer zu realisieren, von der drastisch erhöhten Latenz beim Auslagern der Speicher mal ganz von abgesehen...

Wenn man sowas schaffen will, dann brauch es ner Überarbeitung der kompletten GPU ansich.


Der Einfachheit halber werden ja einfach zwei GPUs der Single Karte genommen und zusammen auf einem PCB untergebracht, die Kommunikation geschieht genau so wie bei zwei Einzellkarten über CF/SLI und über das PCIe Interface.

Im Grunde ist ne Dual GPU Karte nix weiter, als zwei fast komplett einzellne Karten zusammen.
 
Ist mir schon alles klar was du sagst, aber trotzdem sollte es kein Ding der unmöglichkeit sein, wer sagt denn auch das das sich die Chips die Bandbreite teilen müssen. Im Prinzip werden die Frames nach heute gängigen Sli Mustern abwechselnd von den einzelnen Chips berechnet. Somit müssen beide Chips mit den gleichen Daten versorgt werden, weshalb ja auch beide die gleichen Daten im VRam liegen haben.

Es sollte also nicht so schwer sein das die Daten einfach an beide Chips gesendet werden, dazu muss man ja nicht die Daten zweimal aus dem VRam fischen und schicken, sondern nur einmal und splitten. Dann würde ich auch keine Engpesse durch eine evtl halbierende Speicheranbindung bekommen.
 
Das läuft eher anders rum, denn die Recheneinheit fordert eine Speicheradresse oder einen Speicherbereich an...
Bei beiden GPUs liegen zwar die gleichen Daten im Speicher, aber sie rendern nicht am selben Stück, sprich sie benötigen Zugriff jeweils auf andere Speicherbereiche.

Nächster Punkt, die Aufteilung des Bildes geschieht Dynamisch man weis also vorher noch nicht, welche Daten welcher GPU zugeteilt sein müssen, daher haben ja jetzt beide GPUs den gleichen Inhalt im Speicher...
bzw. im AFR Modus, rendet die eine GPU schon das nächste Bild, was noch gar nicht dran ist mit ausgeben...
Wenn sich bei dieser Vorrausberechnung was ändert, dann muss die Arbeit verworfen werden. Daher skaliert das ganze mit steigender GPU Anzahl auch immer schlechter, weil immer mehr Bilder im Vorraus berechnet werden müssen...

Aber wie schon angesprochen, die Speicherbandbreite ansich sollte nicht so schwer zu realisieren sein, viel eher die Anbindung dieses shared Speichercontrollers an die beiden GPUs...
Um die Wege (und somit die Latenz) kurz zu halten müsste man quasi alles so nah wie möglich zusammen pappen, sprich alles in einen DIE und dann über ne Logik verbinden.
Aber das bringt wieder den Nachteil mit sich, das es dann keine Dual GPU Karte mehr ist sondern ein großer Chip, wenn man so will ;)

Weiteres Problem, es bleibt ne Neuentwicklung, sprich man könnte eben nicht einfach die GPUs der Top SingleKarte nehmen und dort zusammen pappen. (Ne Neuentwicklung only für den absoluten HighEnd Bereich macht auf Grund des geringen Absatzes wohl auch wenig Sinn)
 
Zuletzt bearbeitet:
@Scully: Naja, das ist nur mehr oder weniger das, was ich gesucht habe. Da steht ja eigentlich nur, dass der Support für 64-Bit-Zahlen, also Doubles oder Longs, realisiert wird, indem man sie auf mehrere 32-Bit-Multiplikationsoperationen aufteilt. Das klärt aber immer noch nicht die frage, wie eine von diesen 32Bit-Multiplikationen in einem Takt realisiert werden soll - was ja fast offensichtlich der Fall ist.
 
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