PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : CF / SLI - Warum bekommt man die MR nicht in den Griff?


john carmack
2010-08-11, 14:14:45
Hallo Leute,

also irgendwie begreife ich das nicht.
Warum bekommt man die MicroRuckler nicht in den Griff?


Zu Zeiten von 3Dfx gab es sotewas nicht!

Und wenn ich da mal an die Ati Fury Maxx Karte erinnern darf.
(Die hatte 2x Ati Rage 128Pro mit 2x 32MB Ram und war somit die erste Dualchipkarte mit AFR Technik (Alternate Frame Rendering. Jeder Chip berechnet ein Bild und die Chips wechseln sich ab)) Da gab es solche Probleme auch nicht.

PulsarS
2010-08-11, 14:23:33
Weil eine Grafikkarte nicht hellsehen kann.

Gast
2010-08-11, 14:27:04
Weil man nicht will.
Jedes Stückchen Balken ist heilig. So geht die Geschichte ihren Lauf, das ist der Grund das es überhaupt MGPU, statt stärker Single GPUs gibt.

john carmack
2010-08-11, 14:28:34
? aha ?

Sehr intelligente Antwort...

LovesuckZ
2010-08-11, 14:32:08
Synchronisierung der Karten benötigt seine Zeit - kostet also Frames. mGPU in Form "einer" Karte hat jedoch nur einen Zweck: Die längsten Balken zu produzieren. Jede Anstrengungen, die Nachteile der Mikroruckler zu beseitigen, ist also kontraproduktiv.
mGPU ist also nur der verzweifelte Versuch, die Leistungskrone zu haben.

Exxtreme
2010-08-11, 14:44:14
Synchronisierung der Karten benötigt seine Zeit - kostet also Frames. mGPU in Form "einer" Karte hat jedoch nur einen Zweck: Die längsten Balken zu produzieren. Jede Anstrengungen, die Nachteile der Mikroruckler zu beseitigen, ist also kontraproduktiv.
mGPU ist also nur der verzweifelte Versuch, die Leistungskrone zu haben.
Eine richtige Synchronisierung ist schon technisch gar nicht möglich da man von vorneherein wissen müsste wie lange die andere Grafikkarte für das nächste Bild brauchen wird um dann die passende Wartezeit festzusetzen.

Man kann das natürlich schätzen indem man unterstellt, dass die andere Grafikkarte ähnlich lange brauchen wird wie die aktuell aktive. Nur ist das eben nicht synchron und bei Szenen, die hohe Lastwechsel verursachen geht die Schätzung wohl daneben.

john carmack
2010-08-11, 15:04:18
Dann MUSS man eben einen anderen Weg gehen. Ist das denn sooo schwer?

Exxtreme
2010-08-11, 15:06:41
Dann MUSS man eben einen anderen Weg gehen. Ist das denn sooo schwer?
Schwer nicht. Nur viel kostspieliger bei gleichzeitiger Reduzierung der potentiellen Balkenlänge.

Byteschlumpf
2010-08-11, 15:34:51
Seit nicht ganz zwei Wochen betreibe ich zwei GTX460er im SLI und die besagten Mikroruckler stellen die absolute Ausnahme dar! Nachladeruckler treten dagegen praktisch immer früher oder später auf, wobei ich Mikroruckler aus eigener Erfahrung als überaus "seltene Spezies" bezeichnen würde! ;)

InsaneDruid
2010-08-11, 15:58:57
Hallo Leute,

also irgendwie begreife ich das nicht.
Warum bekommt man die MicroRuckler nicht in den Griff?


Zu Zeiten von 3Dfx gab es sotewas nicht!

Und wenn ich da mal an die Ati Fury Maxx Karte erinnern darf.
(Die hatte 2x Ati Rage 128Pro mit 2x 32MB Ram und war somit die erste Dualchipkarte mit AFR Technik (Alternate Frame Rendering. Jeder Chip berechnet ein Bild und die Chips wechseln sich ab)) Da gab es solche Probleme auch nicht.

da wird es solche probleme auch gegeben haben. Erst Tomb hat diese Probleme an die Öffentlichkeit gezerrt, und auch von da an dauerte es ne ganze weile, bis diese probleme anerkannt wurden.


Problem des ganzen ist AFR, welches die Renderzeit eines einzelnen Bildes gegenüber der Single Chip Lösung in keinster weise verringert. 3dfx Lösung, bei der beide Chips sich die berechnung eines Bildes teilten war dahingehend bedeutend geschickter. Denn nur somit bekommt erreicht man echte Mehrperformance und sinkenden statt steigenden Outputlag.

Exxtreme
2010-08-11, 16:34:56
Problem des ganzen ist AFR, welches die Renderzeit eines einzelnen Bildes gegenüber der Single Chip Lösung in keinster weise verringert. 3dfx Lösung, bei der beide Chips sich die berechnung eines Bildes teilten war dahingehend bedeutend geschickter. Denn nur somit bekommt erreicht man echte Mehrperformance und sinkenden statt steigenden Outputlag.
3dfx machte sowas Ähnliches wie Supertiling und hatte AFAIK so ziemlich die selben Probleme.

Nighthawk13
2010-08-11, 16:36:20
Das Problem liegt in modernden 3D-Programmierung: Render-to-Texture, dann Post-processing, dann die Textur als Environmentmap in der eigentlich Szene verwenden. Das Ganze für alle 10 spiegelnde Objekte der Szene. Und die Zwischenbilder natürlich in einer Riesen-Auflösung, damit man sie auch nicht über den PCI-E Bus jagen könnte. (Nur mal als übertriebenes Beispiel)

Der Grafiktreiber kann für komplexe Renderer eigentlich nur AFR anbieten. Für einfache Fälle, wo "nur" ein paar 3D-Modelle mit teueren Pixelshader in den Riesen-Framebuffer rendert, macht "Split-Screen" rendering Sinn. Das war Stand der Technik zu Zeiten von Voodoo2.

Man_In_Blue
2010-08-11, 16:58:22
Hi,

es gibt einige ansätze das Problem zu lösen.

Bereits vor 3-4 Jahren hab ich bei Tweaker.de (leider mittlerweile offline...) einen Artikel über Methoden verfasst um eine optimale Lastverteilung und synchronisierung von Mehr-GPU-Karten zu erzielen.

Einer der besten ansätze ist meiner Meinung nach das dynamische, Multi-Processing-Tiled-Base-Rendering. Wie beim klassischem TBR (bekannt von den Kyro Karten) wird der zu berechnende Frame in ein Schachbrettmuster geteilt. (kann auch gröber sein als beim TBR... 16X16 Tales sollten vollkommen ausreichen)

Die Grafikakrten arbeiten nun die einzelnen Kacheln ab. Hier wäre nochmal wichtig das der Vorgang dynamisch abläuft, heißt die GPUs starten bei Kachel 1 und 2, die GPU welche als erste fertig ist fängt bereits mit Kachel 3 an... bis der Frame komplett ist... so erreicht man ein fast perfektes Load-Blancing und Micro-Ruckler sind auch Adee...

Ich schau mal ob ich den entsprechenden Artikel noch finde...

Sören

Nevermore4ever
2010-08-11, 17:16:45
Grundsätzlich müssten die Frametimes vom Treiber gemessen werden und jedes zweite (und dritte bei Triple-SLI) Bild ein paar ms verschoben werden. Leider führt das zu etwas Lag, weil man ja die Frametime erst hat, wenn das nächste Bild schon fertig ist. Also könnte man versuchen, sich an den notwendigen Wert anzunähern, indem man die Frametimes der letzten paar Frames zum Vergleich heranzieht und hofft, dass der Lag nicht auffällt.

Das Problem, dadurch evtl. den Balken zu verkürzen, könnte man durch Treiberoptionen wie "Smooth Mode" vs. "Speed Mode" oder so beheben, also, jedem den Rendermodus geben, den er persönlich will. Ähnlich ging es ja mit der trilinearen Optimierung aus.

Und nichts desto weniger sehe ich den größten Vorteil und die Zukunft von SLI eben in SLI-Anti-Aliasing und 3D Stereo, weil ich erwarte, dass man sich um die Mikroruckler dabei viel leichter herum drücken kann.

InsaneDruid
2010-08-11, 17:25:46
3dfx machte sowas Ähnliches wie Supertiling und hatte AFAIK so ziemlich die selben Probleme.

Da beim SLI Scan Line Interleaving eine Karte die geradzahligen Zeilen, und die andere die ungeradzahligen renderte, verkürzte sich die Renderdauer gegenüber einem Single Cip. Eben das was heutige AFR Systeme nicht anbieten.

N0Thing
2010-08-11, 17:49:32
Einer der besten ansätze ist meiner Meinung nach das dynamische, Multi-Processing-Tiled-Base-Rendering. Wie beim klassischem TBR (bekannt von den Kyro Karten) wird der zu berechnende Frame in ein Schachbrettmuster geteilt. (kann auch gröber sein als beim TBR... 16X16 Tales sollten vollkommen ausreichen)

Die Grafikakrten arbeiten nun die einzelnen Kacheln ab. Hier wäre nochmal wichtig das der Vorgang dynamisch abläuft, heißt die GPUs starten bei Kachel 1 und 2, die GPU welche als erste fertig ist fängt bereits mit Kachel 3 an... bis der Frame komplett ist... so erreicht man ein fast perfektes Load-Blancing und Micro-Ruckler sind auch Adee...

Ist diese Methode denn bei den aktuell verwendeten Grafikengines überhaupt einsetzbar? Oder hat man einfach nur keinen so großen Zugewinn bei der Zahl der pro Sekunde berechneten Frames?

Coda
2010-08-11, 17:53:29
Einer der besten ansätze ist meiner Meinung nach das dynamische, Multi-Processing-Tiled-Base-Rendering. Wie beim klassischem TBR (bekannt von den Kyro Karten) wird der zu berechnende Frame in ein Schachbrettmuster geteilt. (kann auch gröber sein als beim TBR... 16X16 Tales sollten vollkommen ausreichen)
Das können die ATIs und nein es ist keine Lösung.

Gast
2010-08-11, 17:58:11
Das können die ATIs und nein es ist keine Lösung.

Es wäre eine Lösung wen man einen Interconnector hätte der mehrere 100GB/s durchschaufelt.

Man_In_Blue
2010-08-11, 17:58:35
Das können die ATIs und nein es ist keine Lösung.

Nein, das können die ATis nicht...

ATi hat ne Zeitlang mit Schachbrettzuweisung experimentiert, jedoch keiner dynamischen. Sprich jede 2. Kachel gehört der GPU 2 und die anderen GPU 1. ...

Das ist nicht so schlim wie das PGC das nVidia anfangs verbrochen hat, aber der entscheidende Vorteil der von mir eben angeschnittenen Lösung ist ebend der das die Kacheln NICHT fest zugewiesen werden. Eben dadurch wird ein sehr gutes load-balancing erreicht und Mikroruckeln fast vollständig vermieden. Und das OHNE aufwendiges abgleichen und synchronisieren der GPUs...

Sören

Gast
2010-08-11, 18:11:44
Seit nicht ganz zwei Wochen betreibe ich zwei GTX460er im SLI und die besagten Mikroruckler stellen die absolute Ausnahme dar! Nachladeruckler treten dagegen praktisch immer früher oder später auf, wobei ich Mikroruckler aus eigener Erfahrung als überaus "seltene Spezies" bezeichnen würde! ;)
Du bist halt die meiste Zeit nicht im kritischen Bereich. Stell mal die Settings so ein, dass du bei ca. 35 fps bist, dann merkst die Ruckler. Es ruckelt zwar anders und subtiler als Single-18 fps, aber rund ist es nicht.

Der_Korken
2010-08-11, 20:34:35
Nein, das können die ATis nicht...

ATi hat ne Zeitlang mit Schachbrettzuweisung experimentiert, jedoch keiner dynamischen. Sprich jede 2. Kachel gehört der GPU 2 und die anderen GPU 1. ...

Das ist nicht so schlim wie das PGC das nVidia anfangs verbrochen hat, aber der entscheidende Vorteil der von mir eben angeschnittenen Lösung ist ebend der das die Kacheln NICHT fest zugewiesen werden. Eben dadurch wird ein sehr gutes load-balancing erreicht und Mikroruckeln fast vollständig vermieden. Und das OHNE aufwendiges abgleichen und synchronisieren der GPUs...

Sören

Was aber ist mit der Berechnung der Geometrie? Vorab: Ich bin auf dem Gebiet ein Laie, aber ich habe zum Beispiel in den Speku-Threads gelesen, dass sich die Entwickler sehr schwer damit tun, die Berechnung der Geometrie zu parallelisieren, auch innerhalb einer GPU. Deswegen kann ich mir nicht vorstellen, dass die Lösung dieses Problems so trivial ist, wie du es darstellst.

john carmack
2010-08-11, 22:53:31
Hi,

es gibt einige ansätze das Problem zu lösen.

Bereits vor 3-4 Jahren hab ich bei Tweaker.de (leider mittlerweile offline...) einen Artikel über Methoden verfasst um eine optimale Lastverteilung und synchronisierung von Mehr-GPU-Karten zu erzielen.

Einer der besten ansätze ist meiner Meinung nach das dynamische, Multi-Processing-Tiled-Base-Rendering. Wie beim klassischem TBR (bekannt von den Kyro Karten) wird der zu berechnende Frame in ein Schachbrettmuster geteilt. (kann auch gröber sein als beim TBR... 16X16 Tales sollten vollkommen ausreichen)

Die Grafikakrten arbeiten nun die einzelnen Kacheln ab. Hier wäre nochmal wichtig das der Vorgang dynamisch abläuft, heißt die GPUs starten bei Kachel 1 und 2, die GPU welche als erste fertig ist fängt bereits mit Kachel 3 an... bis der Frame komplett ist... so erreicht man ein fast perfektes Load-Blancing und Micro-Ruckler sind auch Adee...

Ich schau mal ob ich den entsprechenden Artikel noch finde...

Sören


:smile:

Hört sich sehr logisch und auch wirklich gut an.

Und die Frage muss jetzt natürlich kommen: Warum wird Dynamisches "Multi-Processing-Tiled-Base-Rendering" nicht eingesetzt?

john carmack
2010-08-11, 23:01:55
Es wäre eine Lösung wen man einen Interconnector hätte der mehrere 100GB/s durchschaufelt.

Dann halt zu den zwei SLI/CF Karten noch eine dritte kleine die eben nur "Interconnected" :-)

Also eben eine dritte Karte die NUR SYNCHRONISIERT!

Sollte doch machbar sein...

john carmack
2010-08-11, 23:26:07
Mir fällt gerade ein das doch der "Lucid Hydra" Chip Micro Ruckler doch schon sehr verminder soll - Wenn denn die wirklich miesen Treiber nicht wären.

Stimmt das?


**********************************
**********************************

Vielleicht passiert mit dem Lucid Hydra das gleiche wie mit Ageia PhysX :-) :-) :-)

svenw
2010-08-12, 08:54:43
Die Frage wird bald wesentlich aktueller werden, denn über kurz oder lang ist das Ende der Single Graka bald erreicht.

Bestes Beispiel ist die GF100 die schlichtweg nicht vernünftig zu fertigen ist. Okay, 28nm wird noch einen Schub geben, aber ob man dann so weiter machen kann mit immer breiteren Chips und steigender Komplexität wage ich zu bezweifeln. Über kurz oder lang wird man für eine gesteigerte Leistung auf Multi-Chip Lösungen umschwenken müssen (wobei nicht jeder Chip ein kompletter Chip im heutigen Sinne sein muß). Am Ende wird es wohl auf eine Master-Slave Architektur hinauslaufen nur dann muß man die Verteilung der Last natürlich gut im Griff haben.

Exxtreme
2010-08-12, 09:01:02
Nein, das können die ATis nicht...

ATi hat ne Zeitlang mit Schachbrettzuweisung experimentiert, jedoch keiner dynamischen. Sprich jede 2. Kachel gehört der GPU 2 und die anderen GPU 1. ...

Das ist nicht so schlim wie das PGC das nVidia anfangs verbrochen hat, aber der entscheidende Vorteil der von mir eben angeschnittenen Lösung ist ebend der das die Kacheln NICHT fest zugewiesen werden. Eben dadurch wird ein sehr gutes load-balancing erreicht und Mikroruckeln fast vollständig vermieden. Und das OHNE aufwendiges abgleichen und synchronisieren der GPUs...

Sören
Das spielt keine Rolle. Selbst mit einer dynamischen Kachelzuweisung hättest du ähnliche Probleme wie mit einer statischen. Problematisch wird es z.B. wenn Grafikkarte 1 Content rendert, den die Grafikkarte 2 braucht um weiter zu machen. Dann darf die Grafikkarte 2 so lange warten bis Grafikkarte 1 fertig ist.

Mit AFR entfällt diese Problematik komplett.

N0Thing
2010-08-12, 11:12:28
Problematisch wird es z.B. wenn Grafikkarte 1 Content rendert, den die Grafikkarte 2 braucht um weiter zu machen. Dann darf die Grafikkarte 2 so lange warten bis Grafikkarte 1 fertig ist.

Mit AFR entfällt diese Problematik komplett.

Die einzelnen Kacheln sollten sich doch bei diesem Konzept unabhängig berechnen lassen, oder warum braucht Grafikkarte A für die Berechnung einer Kachel Ergebnisse der Grafikkarte B?

Exxtreme
2010-08-12, 11:18:52
Die einzelnen Kacheln sollten sich doch bei diesem Konzept unabhängig berechnen lassen, oder warum braucht Grafikkarte A für die Berechnung einer Kachel Ergebnisse der Grafikkarte B?
Nehmen wir doch mal eine Spiegelung. Grafikkarte A rendert den Spiegel während Grafikkarte B den Content rendert, der dann im Spiegel erscheinen soll. Grafikkarte A wird solange warten müssen bis Grafikkarte B fertig ist.

robbitop
2010-08-12, 11:20:34
Die einzige Lösung, damit das ganze transparent und µRucklerfrei funktioniert würde eine relativ latenzarme Verbindung mit mehreren 100 GiB/s zwischen den GPUs benötigen.

Ich glaube dazu müssten beide Cores recht nah beieinander liegen. Vermulich auf dem gleichen Träger.

AFR ist heute wirklich die einzige gangbare Lösung. Man könnte das µRuckeln durch eine Verschiebung der Frames mit Statistik für die Frametimes aus der nahen Vergangenheit sicher ein wenig tunen (auch wenn's ab und an mal daneben hauen würde). Irgendetwas hat NV ja schonmal dran gemacht, denn das µRuckeln soll bei SLI AFAIK weniger stark ausfallen als bei CF.

IMO würde aber eine zeitliche Verschiebung des Framebuffers von Karte 1 nicht genügen. Das Bild stammt nämlich vom Zeitpunkt (und damit vermutlich auch sämtliche Positionen der Bildgeometrie, solange sich irgendwas auf dem Bildschirm bewegt), der dann obsolet ist und es dürfte dann auch noch zu einer Art juddering kommen. Bestes Beispiel ist eine gleichmäßige Kamerafahrt.

Nehmen wir doch mal eine Spiegelung. Grafikkarte A rendert den Spiegel während Grafikkarte B den Content rendert, der dann im Spiegel erscheinen soll. Grafikkarte A wird solange warten müssen bis Grafikkarte B fertig ist.
Und müsste dann die "Texture" des Spiegels von Grafikkarte A über PCIe rüberziehen, right?

Gast
2010-08-12, 11:31:36
Es gab mal vor ein paar Jahren Tech-Demos mit mehreren PS3. Es ging um entweder viel FPS oder große Auflösungen. Dazu haben vier Konsolen ein Spiel GT5 gleichzeitig gerendert. Die haben also vier ganze Konsolen synchron zum laufen gebracht. Es gibt ja noch Forza 2 auf Xbox360 wo man mit drei Konsolen an einem 180° Bild rechnet - auch synchron.

Exxtreme
2010-08-12, 11:35:59
Und müsste dann die "Texture" des Spiegels von Grafikkarte A über PCIe rüberziehen, right?
Japp, beide Grafikkarten müssen irgendwannmal auf dem gleichen Stand sein. Mag sein, dass man diese Effekte mit weiteren 3D-API-Erweiterungen minimieren kann aber derzeit sieht es wohl eher mau aus. Deshalb ist AFR das Mittel der Wahl. Viel billiger und effizienter bezüglich FPS/Aufwand.

InsaneDruid
2010-08-12, 11:57:05
Es gab mal vor ein paar Jahren Tech-Demos mit mehreren PS3. Es ging um entweder viel FPS oder große Auflösungen. Dazu haben vier Konsolen ein Spiel GT5 gleichzeitig gerendert. Die haben also vier ganze Konsolen synchron zum laufen gebracht. Es gibt ja noch Forza 2 auf Xbox360 wo man mit drei Konsolen an einem 180° Bild rechnet - auch synchron.
das ist aber was anderes, die gezeigten demos waren ja multimonitorsysteme, bei der jede ps3/box einen monitor bedient, ähnlich wie es beim flight simulator seit jahrzehnten beim pc machbar ist mit mehreren pc.

Schlammsau
2010-08-12, 12:10:45
Ich finde zB die µR nicht so schlimm wie den Inputlag unter 25-30fps. Dagegen sollte man was tun!

Mond
2010-08-12, 12:17:44
SLI hat Inputlag? Ich dachte sowas würde in erste Linie vom Monitor abhängen?

Exxtreme
2010-08-12, 12:18:11
Ich finde zB die µR nicht so schlimm wie den Inputlag unter 25-30fps. Dagegen sollte man was tun!
Microruckler sind nicht "schlimm". Sie führen nur den Einsatz von SLI/CF ad absurdum.

Demirug
2010-08-12, 12:24:08
Japp, beide Grafikkarten müssen irgendwannmal auf dem gleichen Stand sein. Mag sein, dass man diese Effekte mit weiteren 3D-API-Erweiterungen minimieren kann aber derzeit sieht es wohl eher mau aus. Deshalb ist AFR das Mittel der Wahl. Viel billiger und effizienter bezüglich FPS/Aufwand.

Nicht nur irgendwann sondern in der Regel mehrmals pro Frame. Bis die Daten kopiert sind ginge dann auf beiden Karten gar nichts mehr. Dagegen lässt sich auch kaum etwas mit entsprechenden APIs machen. Zudem werden ja heute in der Regel noch nichteinmal die AFR optimierungen richtig implementiert und der Treiber muss das übernehmen.

Exxtreme
2010-08-12, 13:01:14
Nicht nur irgendwann sondern in der Regel mehrmals pro Frame. Bis die Daten kopiert sind ginge dann auf beiden Karten gar nichts mehr. Dagegen lässt sich auch kaum etwas mit entsprechenden APIs machen. Zudem werden ja heute in der Regel noch nichteinmal die AFR optimierungen richtig implementiert und der Treiber muss das übernehmen.
Mhhh, wenn man es schaffen würde, dass der Grafikchip von Grafikkarte A direkt den RAM der Grafikkarte B adressieren könnte dann wäre zumindest diese Problematik weg, oder? Gut, beide Grafikchips würden sich u.U. in die Quere kommen was die Speicherzugriffe angeht aber das lässt sich sicherlich etwas minimieren.

Der_Korken
2010-08-12, 15:19:47
SLI hat Inputlag? Ich dachte sowas würde in erste Linie vom Monitor abhängen?

Prinzipbedingt ja, denn wenn 2 Bilder gleichzeitig berechnet werden, sind auch beide doppelt so lange in der Berechnung. Bei 30fps dauert die Berechnung eines Bildes nicht mehr 33ms, sondern 66ms, ergo hat man eine um 33ms höhere Bildverzögerung, als ohne SLI. Je mehr Karten im SLI-System arbeiten, desto extremer wird dieser Effekt.

ChainSOV
2010-08-12, 16:44:44
das ist aber was anderes, die gezeigten demos waren ja multimonitorsysteme, bei der jede ps3/box einen monitor bedient, ähnlich wie es beim flight simulator seit jahrzehnten beim pc machbar ist mit mehreren pc.
die brauchen auch synchronisierung, weil die bilder der einzelnen monitore ja optimaelerweise schon zueinander passen sollten.
wie das die xbox360 ueber ein 100mbit lan schafft? sie werden wohl etwas an synchronitaet sparen, so dass die bilder etwas asynchron kommen, wie auch in MultiPC Multimon Praesentationen von FSX.

Sonst wuerde ja noch Nvidias TriSLI mit 3 Monis im Surround vollkommen MRfrei laufen :rolleyes:

Gast
2010-08-12, 17:21:12
Mhhh, wenn man es schaffen würde, dass der Grafikchip von Grafikkarte A direkt den RAM der Grafikkarte B adressieren könnte dann wäre zumindest diese Problematik weg, oder? Gut, beide Grafikchips würden sich u.U. in die Quere kommen was die Speicherzugriffe angeht aber das lässt sich sicherlich etwas minimieren.

Warum währe es dann weg?
Die Speicherzugriffe dauern aus GPU-Sicht Ewigkeiten.
Wenn die Kommunikation über den Ram so schnell währe, gäbe es so etwas wie L3-Caches auf CPU gar nicht.

Coda
2010-08-12, 17:44:09
Nein, das können die ATis nicht...

ATi hat ne Zeitlang mit Schachbrettzuweisung experimentiert, jedoch keiner dynamischen. Sprich jede 2. Kachel gehört der GPU 2 und die anderen GPU 1. ...

Das ist nicht so schlim wie das PGC das nVidia anfangs verbrochen hat, aber der entscheidende Vorteil der von mir eben angeschnittenen Lösung ist ebend der das die Kacheln NICHT fest zugewiesen werden. Eben dadurch wird ein sehr gutes load-balancing erreicht und Mikroruckeln fast vollständig vermieden. Und das OHNE aufwendiges abgleichen und synchronisieren der GPUs...

Sören
Das spielt keine Rolle. Auch eine dynamische Variante würde das Problem nicht lösen, weil die Performance genauso beschissen wäre. Übrigens gibt es auch mit SFR und "statischem Schachbrett" keine Mikroruckler.

Bei allem Respekt, aber du hast die Sachlage nicht ansatzweise verstanden.

Man_In_Blue
2010-08-13, 13:07:02
:smile:

Hört sich sehr logisch und auch wirklich gut an.

Und die Frage muss jetzt natürlich kommen: Warum wird Dynamisches "Multi-Processing-Tiled-Base-Rendering" nicht eingesetzt?

Das Konzept wurde von 3DLabs (als diese noch eigenständig wahren) erforscht. Kann sein das da nun irgendwer en Patent oder ne Lizenz drauf hat.


@ Coda: Jedem seine Meinung...

Das Problem der unregelmäßigen Frame-Ausgabe ist nicht neu und wir haben uns bereits zu Voodoo3 Zeiten damit befasst... Das ist nichts neues und solange es sich im akzeptablem Rahmen hält ist und war es immer zu vernachlässigen.

AFR ist ein extrem da jeweils zwei Frames sehr nach bei einander liegen. Gut man kann jetzt zu Gunsten von AFR den riesengroßen kleine-Zwergenaufstand blasen mit Framecontrolling und haste-nicht gesehen... oder man denkt ein wenig wirtschaftlicher und verbessert das Konzept oder verabschiedet sich von AFR.

Sören

Exxtreme
2010-08-13, 13:13:57
oder man denkt ein wenig wirtschaftlicher und verbessert das Konzept oder verabschiedet sich von AFR.

Sören
Dann zeig uns doch ein Konzept, welches funktionieren würde.


MfG

corvus
2010-08-13, 13:16:51
Seit nicht ganz zwei Wochen betreibe ich zwei GTX460er im SLI und die besagten Mikroruckler stellen die absolute Ausnahme dar! Nachladeruckler treten dagegen praktisch immer früher oder später auf, wobei ich Mikroruckler aus eigener Erfahrung als überaus "seltene Spezies" bezeichnen würde! ;)

Du hängst immer an einem "Gummiband" beim Spielen mit SLI oder CF.
Bau eine aus und spiele und mal nicht auf die FPS dabei achten...wenn du dann keinen Unterschied feststellst, Hut ab.

RavenTS
2010-08-14, 22:30:33
Und müsste dann die "Texture" des Spiegels von Grafikkarte A über PCIe rüberziehen, right?

Warum über PCIe und nicht über die üblichen "SLI-Verbindungsbrücken"?

...
Und wenn ich da mal an die Ati Fury Maxx Karte erinnern darf.
(Die hatte 2x Ati Rage 128Pro mit 2x 32MB Ram und war somit die erste Dualchipkarte mit AFR Technik (Alternate Frame Rendering. Jeder Chip berechnet ein Bild und die Chips wechseln sich ab)) Da gab es solche Probleme auch nicht.

Bist du dir da absolut sicher, daß es die Problematik damals echt nicht gab oder sie einfach noch nicht erkannt wurde.?!

robbitop
2010-08-15, 08:57:55
Warum über PCIe und nicht über die üblichen "SLI-Verbindungsbrücken"?
Das wäre auch eine Mölichkeit. Mehr Bandbreite haben die Verbindungsbrücken aber auch nicht.



Bist du dir da absolut sicher, daß es die Problematik damals echt nicht gab oder sie einfach noch nicht erkannt wurde.?!
Gab es mit Sicherheit! Die Rage Fury Maxx arbeitete mit AFR. Ergo µRuckler. Das hat damals aber kaum einer einzuschätzen versucht. War auch recht wenig verbreitet die Karte.

RavenTS
2010-08-15, 12:27:52
Das wäre auch eine Mölichkeit. Mehr Bandbreite haben die Verbindungsbrücken aber auch nicht.
...

Könnte man die Bandbreite nicht durch ein Neudesign vergrößern? Die Stecker haben sich mit Einführung der Triple SLI/CF Modi doch auch schonmal verändert, das sollte doch kaum ein großes Problem darstellen...

Exxtreme
2010-08-15, 16:02:22
Könnte man die Bandbreite nicht durch ein Neudesign vergrößern? Die Stecker haben sich mit Einführung der Triple SLI/CF Modi doch auch schonmal verändert, das sollte doch kaum ein großes Problem darstellen...
Problem ist wohl weniger die Bandbreite sondern viel eher die Latenz.

svenw
2010-08-16, 09:31:56
Solche Probleme das z.B. Spiegel von anderen Geometrien abhängen gibt es doch auch auf Single Karten, da muß es doch eine Lösung für geben. Und außerdem muß die eine Graka ja nicht unbedingt Däumchen drehen während sie auf Daten von der zweiten Graka wartet, die zu bearbeiteten Daten sind ja hochgradig parallel bearbeitbar, dann kümmert sich Graka 1 eben um was anderes bis die Daten da sind.

Allein wegen der Chip Größe vermute ich, das es über kurz oder lang einen Masterchip mit angeschlossenen Rechenknechten geben wird. Das hätte für die Chiphersteller den Vorteil das sie nur noch einen Masterchip + Rechenknecht designen müßten und dann je nach gewünschter Leistung die Boardhersteller mehr oder weniger Slaves auf das Board pappen.

Exxtreme
2010-08-16, 11:45:18
Solche Probleme das z.B. Spiegel von anderen Geometrien abhängen gibt es doch auch auf Single Karten, da muß es doch eine Lösung für geben. Und außerdem muß die eine Graka ja nicht unbedingt Däumchen drehen während sie auf Daten von der zweiten Graka wartet, die zu bearbeiteten Daten sind ja hochgradig parallel bearbeitbar, dann kümmert sich Graka 1 eben um was anderes bis die Daten da sind.

Die Problematik gibt es sicherlich auch auf einzelnen Karten. Nur da wartet die Grafikkarte nur auf sich selbst und blockiert nicht zusätzlich eine andere.


Und damit die Grafikkarte nicht Däumchen dreht und was anderes macht muss sie erstmal wissen was sie zunächst nicht berechnen darf. Und das muss man erstmal ermitteln was ebenfalls Zeit kostet. Und da bleibt die Frage ob man das nicht gleich komplett berechnet.

Matrix316
2010-08-16, 12:26:12
Lösung: Zwei GPU "Kerne" in einem DIE die auf den gleichen RAM zugreifen können. :) ;) Am besten noch ein schneller Cache zwischen RAM und GPU, falls das was noch bringt.

Grafiklaie
2010-08-16, 18:36:28
Ich verstehe nicht, warum die "dynamische Schachbrett - Berechnung nicht funktionieren soll. Im Endeffekt rechnen beide GPUs doch nur viele Einzelbilder mit ner extrem kleinem FoV für einen Gesamtframe. Warum muss da eine Karte auf die andere warten? Haben denn nicht beide GPUs Zugriff auf die selbe "Datenbank", wo Position, Art und Form der Objekte und Lichtquellen hinterlegt sind und somit auch der Hinweis "Achtung Spiegel"? Oder kommt es zu eigentlich unnötigen Mehrfachberechnungen zu Ineffizienz?

corvus
2010-08-20, 11:32:55
MR hin MR her :-)
Für ein SLI mit 2 480ern zb. die Stock laufen müßte mein i7 schon mit 5 ghz laufen 24/7..um deren Herr zu werden....ich schaff aber nur 4.6 :-) ergo kein SLI ergo keine MR.

Der_Korken
2010-08-20, 15:22:51
Die Problematik gibt es sicherlich auch auf einzelnen Karten. Nur da wartet die Grafikkarte nur auf sich selbst und blockiert nicht zusätzlich eine andere.


Und damit die Grafikkarte nicht Däumchen dreht und was anderes macht muss sie erstmal wissen was sie zunächst nicht berechnen darf. Und das muss man erstmal ermitteln was ebenfalls Zeit kostet. Und da bleibt die Frage ob man das nicht gleich komplett berechnet.


Aber irgendwie muss ein einzelner Grafikchip genau das ja auch wissen. Schließlich hat ein einzelner Chip ebenfalls schon hunderte an "Kernen", die auch alle parallel ausgelastet werden wollen.

robbitop
2010-08-20, 21:20:58
Aber irgendwie muss ein einzelner Grafikchip genau das ja auch wissen. Schließlich hat ein einzelner Chip ebenfalls schon hunderte an "Kernen", die auch alle parallel ausgelastet werden wollen.
Die aber alle über einen Dispatcher gefüttert werden und über eine extrem latenzarme und sehr breitbandige Anbindung aneinander verfügen. Die können also die Informationen "onchip" sehr sehr gut verteilen.
Offchip wird es eben mangels dieser Art der Verbindung sehr tricky. ;)

john carmack
2010-08-26, 16:52:23
Alles nicht so einfach... hehehe :D

Ich finds halt schon arm das man immer noch nix gefunden hat!

Hey - Wir sind im Jahr 2010/2011 - Da muss doch sowas pillepalle sein :D

Iruwen
2010-08-26, 23:59:54
Die aber alle über einen Dispatcher gefüttert werden und über eine extrem latenzarme und sehr breitbandige Anbindung aneinander verfügen. Die können also die Informationen "onchip" sehr sehr gut verteilen.

Warum kann man zwei Chips nicht auf die gleiche Art verbinden?

RavenTS
2010-08-27, 11:26:09
Warum kann man zwei Chips nicht auf die gleiche Art verbinden?

Ich vermute mal weil die Verbindung einfach physikalisch möglichst kurz sein muss, da sonst die Latenzen viel zu stark ansteigen...

Coda
2010-08-27, 13:36:03
@ Coda: Jedem seine Meinung...
Das sind Fakten, keine Meinung.

Bei deinem Verfahren werden die Probleme nicht gelöst, die derzeit SFR oder Supertiling so langsam machen.

Auch haben SFR und Supertiling jetzt schon kein Mikroruckler-Problem. Das tritt nur bei AFR auf.

kmf
2010-08-27, 14:30:27
[...] die derzeit SFR oder Supertiling so langsam machen.

Auch haben SFR und Supertiling jetzt schon kein Mikroruckler-Problem. Das tritt nur bei AFR auf.Ich nehm mal an, das ist wegen dem zusätzlichen Verwaltungsaufwand der Unmengen an Bildschnipseln.

Für mich spielen MR keine so entscheidende Rolle. Ich hab hier zu Hause die Möglichkeit direkt gegeneinander zu testen. Mit einer Einzelkarte ruckelts in kritischen Szenen weitaus heftiger. Ich hab mich deshalb für SLi entschieden. Und wirds mal nicht unterstützt, ist mit 2..3 Klicks eine Karte abgeschaltet bzw. ganz für PhysX reserviert.

Sentionline
2010-08-27, 14:37:00
Ich denke das würde man mit einem seperaten Framechip (so nenn ichs mal) realisieren können, was allerdings Platz auf der Platine brauchen würde. Etwas ähnliches Entwickelt Intel gerade für sein Raytracing Projekt. Ist ein Hardware Threadsplitter Chip, um dem Multicore aber nur Single Thread Problematik entgegenzuwirken. Wird noch ne weile dauern.

Bei Grafikkarten könnte man solch einen Chip zwischen Framebuffer und RAMDAC ankoppeln. Aber wie schon gesagt wurde: Kostet Entwicklung, Chipfläche, Balkenlänge. Da kann man recht lange warten, weil die Notwendigkeit nicht so akut ist. MR ist ja kein Krebs sondern eher ein vereinzelt auftretender Juckreiz.

Coda
2010-08-27, 15:00:09
Ich nehm mal an, das ist wegen dem zusätzlichen Verwaltungsaufwand der Unmengen an Bildschnipseln.
Das Problem ist das wiederverwenden von im Frame erzeugten Daten. Die müssen bei SFR/Supertiling hin- und herkopiert werden, was die Skalierung komplett vernichtet.

Man braucht einen Unified Memory Pool für beide GPUs um das zu fixen. Es gab mal ein NVIDIA-Patent dass 8 der 16 PCIe-Lanes dazu mit der anderen GPU verbindet.

Exxtreme
2010-08-27, 15:09:06
Aber irgendwie muss ein einzelner Grafikchip genau das ja auch wissen. Schließlich hat ein einzelner Chip ebenfalls schon hunderte an "Kernen", die auch alle parallel ausgelastet werden wollen.
Diese Kerne greifen aber auf einen Speicher zu. Sprich, Kern x hat immer die Daten, die Kern y berechnet hat sofort verfügbar. Bei 2 getrennten Grafikchips ist das nicht so. Da hat jeder Grafikchip einen eigenen Speicherbreich von dem der andere Grafikchip nichts weiss.

Innerhalb des Chips kann es aber tatsächlich zu solchen "Stalls" kommen, dass nicht alle Kerne ausgelastet sind und Teile des Chips Däumchen drehen. Dann ist es die Aufgabe der Treiberprogrammierer da zu optimieren.

yahooligan
2010-09-09, 11:08:08
Bin absoluter Laie und weiß nur, dass mich Mikroruckler sehr stören.

Frage:
Ist es vorstellbar, dass die Lösung nicht in den Treibern und den Karten liegt, sondern von Seiten der Spielehersteller was getan werden kann? Bei den CPUs mussten die Chiphersteller auch darauf setzen, dass die Anwendungs- und Spieleprogrammierer ihre Programme auf Multicores optimieren. Ist es nicht möglich die Grafikengine eines Spiels so zu optimieren, dass die GPU Kerne besser zusammenarbeiten können?

Cubitus
2010-09-09, 11:16:58
Bist du sicher das es Mikroruckler sind ?
Oder kommt dir trotz hoher FPS es so vor als ob das Spiel schlechter läuft ?

yahooligan
2010-09-09, 11:38:19
Ich hab kein Dual-GPU Setup. Ich spreche von Mikroruckler-Demovideos. Ist auch egal, vor allem gehts mir um die gestellte Frage.

EvilTechno
2010-09-09, 15:19:14
Coda: Das Problem ist das wiederverwenden von im Frame erzeugten Daten. Die müssen bei SFR/Supertiling hin- und herkopiert werden, was die Skalierung komplett vernichtet.

Und wie wäre es mit dem (unbezahlbaren) brute force Versuch?
Statt im Framebuffer das Bild zusammenzusetzen und im anderen das aktuelle Bild anzuzeigen (und dann wieder zu wechseln) wie wäre es wenn genug Speicher vorhanden wäre um die letzten 10 Fames zu speichern. Damit müsste man doch sogar einen netten Blur Effekt zaubern können.

Würden 8 GB VRAM (bei denen jede GPU auf jedes fertige Bild zugreifen kann) das Problem lösen?

----
Ach ich Dummerchen habe jetzt erst kappiert, dass dann immer noch die Informationen des Vorgängerframes (x-1) fehlen würden, wenn Frame x gerade zusammengesetzt wird.
Es wären also die Infos von (x-2), (x-3), (x-4), ect. vorhanden, aber ausgerechnet der aktuellste Frame fehlt. Macht die Idee wieder sinnlos.

Coda
2010-09-09, 16:06:33
Wer redet denn von den vorherigen Frames? Es geht nur um den Frame der gerendert wird.

Spiele die Daten von vorherigen Frames verwenden gibt es zwar, sind aber äußerst selten.

john carmack
2010-09-19, 12:39:53
Scheint doch ganz schön kompliziert zu sein :D

Piffan
2010-09-22, 11:09:54
Es wird prinzipiell nicht gehen. Einer simplen Logik folgend: Ginge es, gäbe es das. Wenn man sieht, wieviel Hirnschmalz in der Technik schon drin steckt und was für Koryphäen sich mit 3d- Computerei beschäftigen, dann bleibt nur obige Schlussfolgerung...