News Die Multi-GPU-Mikroruckler: Der Stand der Dinge

[Ice =A=]

Sagt mal, kann mir mal einer erklären, wie es in einem SLI-Verbund NICHT zu Microrucklern kommen soll?!?
Da berechnen die Karten doch abwechselnd die Bilder, aber während die eine Karte das nächste Bild berechnet, woher soll da die zweite Karte wissen, welches das übernächste Bild werden soll? Schließlich hängt dieses doch davon ab, wie sich der Spieler bewegt bzw. was in der SPielwelt zwischenzeitlich geschieht?!!!!
Da muss doch ein zwangsläufiger Zeitversatz herrschen, oder nicht?!?

 

[neptune81]

Mir kann da keiner erzählen das beide nichts davon wussten. Die werden doch den Kram testen bevor die solch eine Technik auf den Markt werfen. Jede Wette: Die hofften das unser einer, der kleine Mann das nicht bemerkt und sowohl SLi als auch CF kauft/ verbaut. Es ist traurig, dass WIR in fast sämtlichen Bereichen des PCs zum Betatester avancieren, damit meine ich softwaretechnisches (was ja mittlerweile gang und gebe ist) und nun auch hardwaretechnisches, siehe u.a. billige Mosfets und Capacitors auf Boards zum Preis jenseits der 200€ Marke. Nun das hier. Einfach nur lachhaft.

Zum Glück, haben wir diese MultiGPU Lösung noch nicht zwingend nötig, ansonsten kann man sich vorstellen wie groß der Druck wäre dieses Problem (Mickroruckler) schnellstens zu beseitigen. Alle die derzeit SLi oder CF nutzen tun mir da schlichtweg leid.

Ich persönlich rüste erst auf wenn A) das Problem 100% aus der Welt ist und B) die Notwendigkeit dessen gegeben ist.

viele grüße

 

[jan4321]

Ist ja toll das man sich um dieses Problem gekümmert wird, aber ich hoffe, das dadurch die Leistungssteigerung durch SLI/CrossFire nich noch geringer ausfelt. Wenn die Frames nämlich erst zwischengespeichert werden.

 

[eLw00d]

Selbst wenn´s ein bisschen Leistung kostet...

Hast du dir hier im Forum mal die Werte der "gefühlten" FPS-Verluste durch Mikroruckler angeschaut?
Da sind 40% keine Seltenheit.

Achso, kann man garnicht oft genug sagen:

Danke an CB, dass ihr euch so intensiv mit dem problem auseinander setzt und es mal wieder in die Schlagzeilen bringt!

 

[jan4321]

Hast auch wieder recht

 

[Realsmasher]

Schade, es wird wieder nicht auf unterschiedliche Monitore eingegangen.

Man nehme einen handelsüblichen VA-Monitor der 2-3 Bilder zwischen speichert bevor er sie ausgibt.

Sollte es diesem nicht völlig egal sein ob 2 aufeinanderfolgende Bilder mit unterschiedlichen Abständen eintreffen, weil sie ohnehin erst gespeichert werden und dann normalisiert im 60hz Rhythmus ausgegeben werden ?

Klar, bei einer wildgewordenen TN Kanone die sofort alles zeigt was sie bekommt ist das Problem sicherlich präsent, bei einem Bildpuffer im Monitor kann ich es mir hingegen nicht vorstellen.

Eventuell kann jemand hier von CB mal dazu Stellung nehmen.

 

[Ice =A=]

Diese Zwischenspeicherung von Monitoren würde ja den Zeitversatz zwischen "Jetzt-Zeit" und dargestelltem Bild noch weiter vergrößern! In der c't wurde zum ersten Mal von dem Zeitversatz durch die "Overdrive-Funktion" mancher Monitore berichtet, meinst Du das Problem?

Jedenfalls hätten wir damit schon zwei verschieden Quellen für eine Zeitverzögerung (Monitore und Dual-Grafikkarten), und die beiden addieren sich!

 

[andr_gin]

Sehe ich das richtig? Das mit den Mikrorucklern konnte man sehr lange vertuschen, weil alle nur geil auf die Average FPS sind und hier 2 (fast) gleiche Bilder kurz hinereinander angezeicht werden, wodurch man die doppelten FPS erreicht. Wenn man jetzt die größten Zeitabstände (Minimum 10-20% FPS) misst, dann merkt man, dass SLI/Crossfire so gut wie nichts bringt.
Jetzt kommen Sie mit dem Trick die 2 gleichen Frames nicht kurz hintereinander sondern um ein halbes Frame versetzt anzuzeigen. Damit wird das Ruckeln kein Stück besser, aber man hat einen neuen Weg gefunden, die Statistik auszutricksen, weil wie viel Unterschied zwischen 2 Frames ist, kann man leider nicht so leicht feststellen (Unterschiede kann man ja mit Fraps ganz einfach messen).
Wie groß war der Aufschrei, wie sich ATI bzw. Nvidia 2-3% mehr Leistung auf Kosten von ganz leichten Verschlechterungen an der Bildqualität, die man sogar mit 5 fach Zoom oder diverse Zusatztools zur Analyse von Anisotropen Filtern (einfärben von Schärfegraden) nur sehr schwer feststellen konnte, herausgeholt haben. Jetzt sind es nicht 2-3%, sondern im Fall von Jericho 123% mehr im Vergleichen zwischen Minimum FPS (schlechtester von 4 Frames) und Average FPS.

 

[Blackmarket]

Vielleicht sollten ATI und Nvidia gemeinsam nach Lösungen suchen, sonst werden beiden die Kunden weglaufen ....

 

[neofelis]

Ich bin soo froh, dass diese Diskussion angestossen wurde. Vielleicht kommt man ja doch noch dahin, dass diese ganze Stromverschwende-Technik, wie 3-fach-SLI und 4-fach-Crossfire jenseits von 600 Watt und Gut und Böse endlich zum Teufel geht. Hoffentlich wir es noch eine ganze Weile mikroruckeln und das Auslachen von Benchmarkfreaks weitergehen.

 

[Ice =A=]

@andr_gin:
Ja, so ähnlcih seh ich das.
Am Anfang von SLI gab's ja noch die Variante, dass beide Grafikchips teile desselbgen Bildes gleichzeitig berechneten, das erscheint mir prinzipiell sinnvoll.
Aber das heutige Hintereinanderberechnen würde nur Sinn machen, wenn man als Hellseher wüßte, wie das übernächste Frame (an dem schon Grafikkarte B rechnet) aussehen müsste, noch während das nächste Frame von Grafikkarte A berechnet wird.

Um's nochmal übersichtlich für alle zu sagen (bitte klärt mich auf, wenn ein Denkfehler drin sein sollte):

Beide Grafikkarten rechnen im heute immer verwendeten AlternateFrameRendering-Modus gleichzeitig an verschiedenen Bildern. Das bedeutet aber zwangsläufig, dass während die Grafikkarte A am nächsten Bild arbeitet, die Grafikkarte B schon am übernächsten Bild rechnet. Aber das Spiel kann unmöglich wissen, wie der Spieler sich im nächsten Augenblick bewegt oder was im Spiel passiert, wie kann man da das übernächste Bild sinnvoll berechnen?!?
Die einzige Möglichkeit ist also, dass die angezeigten Bilder immer um ca. 2 frames dem eigentlichen Geschehen "hinterherhinken", und das ist störend und für Hardcore-Gamer absolut untragbar (das bedeutet bei 30fps immerhin einen lag von ca. 60ms) !

Edit:
Da fällt mir auf: Das ganze is ja eigentlich ein neues Problem, das unabhängig von den Microrucklern auftritt!
Sorry! Aber ich finde, das sollte man ruhig mal weiter verfolgen!

 

[Sascha8777]

Auf jedenfall erfreut es mich das zurmindest eine Hersteller an dieses Problem befasst und dies auch zu beheben versucht.

Hast du auch weiter als nur die Hälfte des Textes gelesen? Nvidia sowie ATI arbeiten an dem Problem.



@topic:
Naja wer weiter ist kann man nicht sagen, es gibt weder Tests noch konrete Beweise außer Aussagen etc.

Bisher habe ich glück und bin nicht von den extremen Microrucklern befallen, zumindest noch nie bemerkt.

 

[Realsmasher]

Diese Zwischenspeicherung von Monitoren würde ja den Zeitversatz zwischen "Jetzt-Zeit" und dargestelltem Bild noch weiter vergrößern!

Microruckler sind ungleichmäßige Frametimes.

Die zusätzlichen Lags sind anderen probleme die zwar auch existieren, aber damit überhaupt garnix zu tun haben, deswegen wollte ich darauf auch nicht hinaus.

Die Frametimes dürften durch das zwischenspeichern aber zu 100% geglättet werden, wenn der Monitor eh in 60hz Kadenz die Bilder ausgibt.

 

[Ice =A=]

Vernünftiger Einwand, wir sollten uns erstmal auf ein Problem konzentrieren, nämlich das der Micro-Ruckler.
Und das wäre durch eine kurze Zwischenspeicherung -wie Realsmasher sagt- wohl in den Griff zu kriegen!

Tut mir leid, dass ich da Nebenkriegsschauplätze aufgemacht habe! Allerdings sind die zusätzlichen Lags dann eben das als nächstes anstehende Problem, und das dürfte nicht so leicht zu lösen sein!

 

[Mr. Snoot]

Wieso ist den AFR überhaupt besser als SFR? Nur weil es sich leichter implementieren lässt?

Für mich als Laien macht dieses Ratespielchen, wie könnte der nächste Frame aussehen, gar keinen Sinn. Wenn ich dagegen das Bild in gleiche Häppchen aufteilen (meinetwegen in vertikal Streifen, damit jede Grafikkarte gleichviel Himmel und Boden sieht - oder halt mit Load Balancing), bin ich doch auf der sicheren Seite und muss nicht vorausahnen, was da nun kommen könnte.

Gibt's denn irgendwo Vergleiche von AFR und SFR?

 

[Ice =A=]

Wieso ist den AFR überhaupt besser als SFR? Nur weil es sich leichter implementieren lässt?

Ja, genau!
Na ja, ich glaube, das Problem bei SFR ist (grob gesprochen) folgendes:
Heutzutage werden ja fast alle Grafikeffekte in den Grafikkarten berechnet (Stichwort: Shader). Dabei gibt es z.B. Effekte im unteren Halbbild, die auch die oberen Bereiche des Bildes beeinflussen. Und daher müsste die am oberen Bild rechnende Grafikkarte im Grunde auf die andere warten. Leider gilt das auch umgekehrt, kurz: Das geht bei solchen Effekten nicht...

 

[TchiboMann]

Tjow, dann hat sich das ja mit SLI/Crossfire ja erstma auf mindestens 6 weitere Monate erledigt Hrhr, die armen schweine, die sich sowas zugelegt haben, geld umsonst verpulvert

 

[kisser]

AFR ist nicht dämlich sondern aktuell einfach die effizienteste Multi-GPU-Technik.

Ich würde es so formulieren:

AFR ist derzeit die einzige Multi-GPU-Technik, die theoretisch zu 100% skalieren kann (nämlich VS- und PS-Leistung).
Bei SFR oder ATIs Tiling-Lösung skailert nur die PS-Leistung, weil beide Chip die komplette Geometrie berechnen müssen.

Man könnte dem Mikrorucklerproblem so begegnen, indem man treiberintern einen FPSzähler mitlaufen läßt, und für die Berechnung des Zeitintervalls zweier aufeinanderfolgender Frames einfach den FPS Wert des vorangegangenen Framepaares heranzieht.

Und wo bleibt in deinem Gedankengang die Applikation und die D3D Runtime?
Deine Idee ist im Prinzip schon richtig, aber GPU/Treiber wissen nichts von der Applikation und umgekehrt, d.h. es erfolgt keinerlei Kommuniaktion zwischen ihnen, mit denen sich das steuern ließe. Das läuft alles über die D3D Runtime.

@14
3dfx sli funktionierte ja im interleaving verfahren. da leidet dann unter umständen zwar die bildqualität ansich darunter wenn unterschiede beim DAC auftreten, aber mikroruckler gibts nicht

Unterschiede beim DAC könne nicht auftreten, weil das alles nur über den DAC einer Karte läuft (nämlich der Karte, an der der Monitor hängt)

 

[WiseGuy]

Ich weiß nicht wie das programmiertechnisch ausschaut, aber wenn der Treiber die Karte pausiert (

Dieser soll einen Scheduler enthalten, der die fertigen Frames im richtigen Zeitabstand an den Monitor ausgeben soll.

Allerdings sieht man eine Möglichkeit, indem man die GPUs als „beschäftigt“ deklarieren und man so die Verteilung der Frames beeinflussen könnte.

) werden Applikation und D3D Runtime umgangen.

Bis vor kurzem gabs ja noch das Tool "fpslimiter" (siehe diesen Thread: http://www.forum-3dcenter.org/vbulletin/showthread.php?t=371844), was durch ein Festsetzen der FPS auf einen definierbaren Wert das Problem nachweislich behoben hat. Ich behaupte nun, daß es möglich ist, statt eines fixen FPS Wertes einen variablen Wert zu verwenden. Beispiele: 1000ms / 170fps / 2 GPU Kerne ergäbe eine Pause von ~2.941ms zwischen zwei Frames, wohingegen bei 1000ms / 30fps / 2 GPU Kerne eine Pause von ~16.667ms notwendig wäre.

 

[Suxxess]

Da nach eigenen Aussagen unter Windows Vista der „Command Buffer“, der für die Verteilung der Renderbefehle zuständig ist, vom Kernel des Betriebssystems verwaltet wird und man diesen nicht manipulieren kann.

Also ist eigentlich Vista Schuld an dem Problem, wie sieht es bei Windows XP aus?
Tritt dort das Problem nicht auf, b.z.w. kann man da treibertechnisch schneller helfen?

Was ist mit OpenGL unter Windows XP? (Unter Vista gibt es OpenGL ja nur nativ, quasi beschnitten und verlangsamt wenn ich richtig informiert bin. ) Ist es ein generelles Kernelproblem oder liegt das halt an der Programmierung von Vista.


@Stromsparer
die X2 3870 verbraucht im Idle weniger Saft als so manche Nvidia Singlechiplösung. Hier könnte man trotzdem durch Teildeaktivierungen bei Nichtbenutzung noch Energie einsparen.