[Sammelthread] Nvidia SLI - Nvidia's Scalable Link Interface ***Sammelthread***

  • Ersteller Gelöschtes Mitglied 45455
  • Erstellt am
-SLI- Nvidia's Scalable Link Interface ***Sammelthread***

In diesem Sammelthread soll es um die Konfiguration von SLI gehen. Die wichtigsten Programme nHancer und Rivatuner werden diskutiert und erklärt.
Lösungsvorschläge und Lösungsanfragen für alle möglichen Spiele sind dringendst erwünscht!


---- must have tools ----

nHancer 2.3.2 (02.11.07) http://www.nhancer.com/

RivaTuner 2.06 (02.11.07) www.guru3d.com/rivatuner/ Forum


---- FAQ ----

Wie stell ich fest ob ein Spiel SLI nutzt?
Durch Beobachtung der Temperaturen der Grafikkartenkerne mithilfe des RivaTuner OSD (HowTo).
Wenn nur ein Chip während des Spiels heisser wird dann nutzt das Spiel nur eine Karte und es sollte mit nHancer ein Profil erstellt werden! Alternativ kann man auch die SLI-Lastverteilung von nHancer nutzen oder einfach einen FPS Leistungsschub mit Fraps/RivatunerOSD suchen.

Wie mache ich selber funktionierende Profile?
Man sollte sich erkundigen welche Engine das Problemspiel benutzt und dann ein anderes Profil eines Spiels mit der selben Engine duplizieren, um dann nur noch die *.exe des Problemspiels in das neue Profil aufzunehmen.
(Geht zum Beispiel gut mit UnrealEngine(3) Spielen)
Weiß man nicht welche Engine benutzt wurde, so kann man versuchen ähnliche/Vorgänger Spieleprofile als Vorgabe zu nutzen.
Wenn das alles nicht helfen sollte, dann kann man mal im Internet nach gescheiten Lösungen suchen, bei begehrten Spielen wird man auch oft fündig.


---- Links ----

--- Information/UserGroups/Diskussionen ---

Nvidias SLI Zone: www.slizone.com /Board: http://forums.slizone.com/

Wikipedia Artikel zu SLI

Guru 3D SLI Users Guide
Guru 3D SLI Users Guide (Part #2)

Mikroruckler Sammelthread

--- Guides/HowTo's ---

nHancer Guide

Rivatuner Guides:
OSD HowTo 1 [Deutsch]
OSD HowTo 2 [Englisch]
Fan-Control HowTo [Englisch]
Clock-Speeds HowTo [Englisch]

Sammelthread Version: 0.42 (15.12.07)
 
Zuletzt bearbeitet von einem Moderator:
Zum Vergrößern anklicken....
Redest Du von her Neuanschaffung, oder ner Aufrüstung? Du hast den Prozessor schon, oder die Grakas? Du weißt wie man ein CPU Limit beobachtet?
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Proz und eine gtx 670 sind da und werden schon ein zeitlang benutzt, zwei Monis fürn Schnapper grad im Anflug. Dann kommt noch eine gtx 680 oder auch 670.
 
Also alles schon im Zulauf? Dann ist doch die Frage spätestens dann geklärt, wenn Du das ganze in Betrieb hast, ohne das wir rätseln müssen, bzw. Du schaust einfach auf die Graka-Auslastung wenn Du das ganze in Betrieb hast.
Läuft die auf 99%, dann ist die Graka zu lahm, und eine 2. Graka bringt Punkte. Läuft die deutlich unter 90%, dann ist die CPU zu lahm für das was dargestellt werden soll.
 
Zuletzt bearbeitet:
Das ist doch das tolle an den Dual-Karten, die umgehen die ganze "Vorgeschichte".
Keine 4 Slots, keine 2 x16 Steckplätze, kein SLI-Chipsatz, kein Netzteil mit 2xPCIe
 
I need help.

Hab zwei GTX980 im Rechner eine Referenzkarte und eine Palit Jetsream. (Weitere Systeminfo bzw sysProgfile ist aktuell)
Mir werden beide Karten angezeigt aber die zweit springt nicht an. Egal was ich mache.
Gesternabend hatte ich es einmal kurz. Da ist ein 3DMark test im SLI gelaufen. Seitdem Fehlanzeige.

Das Hauptproblem momentan ist, ich bin nur einmal in die Nvidia Systemsteuerung rein gekommen um SLI einzuschalten. Seitdem tut sich nix mehr wenn ich versuche Sie zu öffnen. Habe nur dieses Nvidia Icon in der Task Leiste rechts unten.
Wenn ich alle Treiber runter schmeiße und neu drauf mache geht es wieder einmal. Danach Fehlanzeige.

Komme nur noch über den Inspector in die Optionen und da bin ich mir nicht sicher mit den Einstellungen.
Wenn ich BF4 anmache springt die zweite Karte nicht an. Auch wenn für das Profil im Inspector alle SLI Optionen eingeschaltet sind.

Was ist das für ein Murx imt der Nvidia Systemsteuerung? Ist das Problem bekannt?
 
sieht so aus als würde as aktuellen treiber 344.65 liegen
mit 344.11 komme ich zwar nach nem neustart auch nicht mehr in die nvidia systemsteuerung aber sli scheint unter 3d mark zu funktionieren
 
Zuletzt bearbeitet:
Hey, ich fahre jetzt das erste mal n SLI System.
Sind die massiven Tempunterschiede der Karten normal? Klar das die obere wärmer wird, bei mir sind es 10-13Grad. (Lukü, kein DHE)
 
Gigabyte GTX 970 Gaming G1
GPU1 ~67 Grad
GPU2 ~55 Grad

Die Temps sind ja gut, ging um den unterschied :)
 
Zuletzt bearbeitet:
Ich habe die Karten einfach mal getauscht, weil mir auffiel das die untere weniger Spannung unter last benötigt (höhere ASIC?!) und dadruch tendenziell eh etwas Kühler bleibt als die oberen.

Jetzt:
GPU1 65Grad (ASIC 71% benötigt 1.17V @ stock) (oben)
GPU2 57Grad (ASIC 66% benötigt 1.2V @ stock)

Differenz ist jetzt nur noch bei 8Grad und die obere GPU läuft etwas leiser als vorher. Ich denke es ist sinnvoll die an sich Kühlere GPU nach oben zusetzen, damit die wärme etwas mehr Luft hat :)
 
Da ich gerade beim Aufrüsten bin,hätte mal eine Frage bezüglich der Skalierung von SLI,Triple-Sli und Quad-SLI.
Woran liegt es denn genau,daß es mit mehreren Karten nicht mehr so gut skaliert?
Ist das treiberbedingt,liegt es an Windows oder allgemein an der Technik.
Bei welchen Spielen skaliert es gut?Gibt es da eine Liste?
 
Gibt keine Liste, wer soll die auch pflegen?
Liegt an der Technik. Wenn Du schon bei normalem SLI nicht immer beide Karten optimal ausgenutzt bekommst, dann kann das mit mehr Karten ja nur schlimmer werden :-)
 
Warum versucht man seitens Nvidia nicht dieses Problem zu lösen?
Wo genau liegt das Problem auf technischer Seite?
Sie und andere Unternehem würden ja dadurch auch profitieren.
Die Politik verstehe ich nicht so wirklich.Da bringt man so Dinge wie SLI,3D-Vision und anderes auf den Markt,pflegt diese Dinge aber nicht.
 
Wieso pflegt? Die Pflege selbst ist ja nicht das Problem und gerade seitens NV ist man da durchaus dran, dass womöglich beste aus dem System zu holen, was geht... Das Problem ist die Technik.

Es ist nunmal so, dass das, was hinten aus dem Monitorausgang bei raus kommen soll eine Abfolge von Bildern ist. Mit MGPU Methoden versucht man mehr davon zur gleichen Zeit rauszubekommen. Nur muss das Ganze auch am Ende wieder zusammenpassen.
MGPU Verfahren bieten mehrere Nachteile. Zum einen hat eine der Karten prinzipbedingt mehr Arbeit, denn diese muss die Bilder der anderen Karten schließlich wieder irgendwie in die Bildabfolge eingliedern. Der nächste Punkt ist die Tatsache, dass es Wartezeiten gibt. Nicht jedes Bild ist gleich schnell fertig berechnet. Da können sonstwelche Faktoren die Berechnungszeit beeinflussen. Und am Ende ist es dann nunmal so, dass die längste Zeit hier der gemeinsame Teiler bleibt.

Beispiel (AFR Rendermodus, der quasi ausschließlich Verwendung findet):
Wenn GPU 1 Bild A berechnet, GPU 2 nun Bild B, für das Übertragen und sonstwelche notwendigen Schritte die Berechnungsdauer von sagen wir 10ms bei GPU 1 aber auf 11ms steigt, hast du nach 11ms nun zwei Bilder. Das wären ca. 182 FPS. Wären beide GPUs gleich schnell, hättest du nach 10ms zwei Bilder. Was 200 FPS wären. -> in diesem Beispiel liegt die SLI Skalierung bei nunmehr 91%, was in etwa durchaus realistisch in der Praxis ist.
Auch so Sachen wie der Threadscheduler des Betriebssystems spielen dabei eine Rolle. Denn idR wird gerade bei MGPU Verfahren mit mehreren Threads gearbeitet. Nur kann es dir passieren, dass diese Threads nicht alle samt die gleiche Rechenzeit bereitgestellt bekommen. Oder aber auch, dass durch andere Threads (wie Hintergrundprozessen, das Spiel selbst usw.) die Recheneinheiten der CPU mehr Zeit für die Aufgabe brauchen und somit ebenso ein Ungleichgewicht zwischen den verschiedenen Teilen besteht.

Das war jetzt bildlich für zwei GPUs. Um so mehr GPUs, desto mehr kommt es dort zu Problemen, da eben der langsamste die Musik vorgibt. Und die jeweils schnelleren Parts müssen zwingend warten, da die Ausgabereihenfolge der Bilder am Ende vorgeschrieben ist.

Man bedient sich bei der MGPU Skalierung dazu auch einigen Tricks. Damalige Messungen (Stichwort FCAT) haben ergeben, dass die Hersteller bei MGPU Verfahren durchaus auchmal bescheißen ;) Sprich es werden ggf. nicht alle berechneten Bilder ausgeben, es werden Bilder nur halb ausgeben oder es werden Bilder länger ausgeben, als notwendig usw.

Da oben drauf kommen Verfahren zum angleichen der Frametimes. Stark schwankende Frametimes haben zur Folge, dass der Mensch am Bildschirm diese Schwankungen bemerkt und sich somit ein hakliges/ruckliges Empfinden einstellt. Um dies zu verhindern werden die Frametimes angeglichen. Bei NV schimpft sich das Frame Metering. Auch dabei geht potentielle Performance verloren, weil die Frameausgabe die Zeiten versucht möglichst glatt zu halten und Schwankungen zu verhindern. -> dieses zurückhalten von Frames bedeutet im Umkehrschluss, dass Leerlauf auf den Recheneinheiten entsteht, weil diese erst weiterrechnen können, wenn hinten im Ausgabepuffer Platz für neue Bilder ist. -> und hier gilt ebenso, um so mehr GPUs da beteiligt sind, desto schlechter die Skalierung allgemein.


Könnte man nun meinen, OK dann nimmt man nicht AFR als Rendermodus, sondern SFR und lässt alle GPUs am gleichen Bild jeweils zu Teilen berechnen -> das wurde ebenso schon versucht und bietet die idR noch beschissenere Skalierung ;) Denn hier kommt es zum Problem, dass die Aufteilung des jeweiligen Bildes möglichst exakt gleich viel Performance benötigen muss. Sonst muss GPU 1 mehr rechnen und benötigt mehr Zeit als GPU 2 -> was die Skalierung wieder verringert. SFR bietet dabei zwar einige eklatante Vorteile, aber die Skalierung ist idR eben extrem mau, da das zerhackstückeln der Bilder für die beteiligten GPUs eher schlecht als recht funktioniert. Und vor allem einige Effekte bspw. Last auf allen GPUs notwendig machen, vor allem dann, wenn sich Teile der Berechnungen über die Teile des Bildes verstreuen müsste jede beteiligte GPU den Effekt berechnen.


Unterm Strich, der AFR Mode ist schon ein guter Kompromiss aus Vor- und Nachteilen. Ob es sich lohnt, da zu investieren und bspw. nen Hardwarescheduler zu entwicklen, der mehrere GPUs da versorgen kann, ist bestenfalls fraglich. Zumal die Ressourcenskalierung über die Hardware selbst auch niemals nie perfekt ist ;) Doppelt so "fette" GPU in allen Bedinungen heist idR auch nicht doppelt so viel Leistung... Und so kommt wieder Eins zum Anderen.
 
Entschuldige,aber bist du Techniker/Ing,/Prof bei NV?:eek:
Das hast du wirklich sehr gut erklärt.Gehört eigentlich sofort in den Threadstart eingefügt.
Man kann also nur darauf hoffen,daß NV diebezüglich mal ein paar Kohlen drauflegt und sich etwas einfallen läßt.

Vielen Dank für diese sehr umfangreiche Erklärung!:hail:
 
Genau genommen liegt es an der Software und dem Bus. In HPC clustern werden kontinuierlich 90% und mehr Skalierung erreicht. Vor allem durch breite Anbindung und einem flexibleren Programmiernodell als die restriktive Schnittstelle Direct 3D. Da helfen auch keine Wunderlinge wie PLX switches mehr. Hauptproblem ist ja dass etwas dreidimensionales nur zweidimensional dargestellt wird.
Dazu kommen noch Schwächen, wie von fdsonne aufgeführt wurde, des AFR-Renderings oder schlechte Lastverteilung.
Hier widerspreche ich auch dass Hardwarescheduling sinnvoller sei da der unendlich komplex sein müsste um alle Probleme abzudecken. Ein guter Compiler sowie guter Programmierer lösen das energiesparender und effektiver ;)
 
Die von ASUS gibt's afaik noch nicht und die andere überall im Ausland. Kostet aber beides saftig Kohle (80-100 Euro).
 
Mein Rat: Schreibe die direkt an mit Bitte um Nennung der Vertriebspartner solcher Brücken. Da dann anrufen (z. B. caseking) und Preis verhandeln.
 
Anmelden, um zu antworten.
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