Archiv verlassen und diese Seite im Standarddesign anzeigen : Wie entstehen Mikroruckler?
svenw
2010-04-20, 08:27:27
Hat jemand zu dem Thema eine gute Seite und/oder Thread? Ich kann nicht ganz verstehen wie die Mikroruckler bei AFR entstehen können. Denn entweder haben beide Frames die gleiche Berechnungsdauer dann gibt es keine MR oder die Berechnungen dauern unterschiedlich lange, dann müßte der Effekt auch auf Single Chip Karten zu sehen sein.:confused:
Die Zeit, die die CPU braucht, um die Daten für einen Frame vorzubereiten, ist wesentlich kürzer als die, die die GPU braucht, um einen Frame zu rendern.
Die Daten kommen also zu GPU 1, diese fängt an zu rendern; die CPU bereitet den nächsten Frame vor und schickt dessen Daten zu GPU 2, die auch zu rendern anfängt. Dann wartet die CPU, bis GPU 1 fertig ist (dauert eine Weile) und kann erst dann die Daten für den nächsten Frame an GPU 1 geben. Kurz darauf wird auch GPU 2 fertig uswusf.
Du hast dann stark verschiedene Zeiten zwischen den einzelnen Frames, also eine sehr kurze Zeit zwischen den Frames von GPU 1 und GPU 2 und eine recht lange Zeit zwischen denen von GPU 2 und GPU 1. Und das empfindet man wohl als Ruckeln.
-huha
Spasstiger
2010-04-20, 15:27:02
http://www.abload.de/img/mikrorucklerv191.png
Eigentlich sollte es von mir mal einen Artikel zu dem Thema geben. Ich werd mich vielleicht mal wieder dransetzen. Inhaltlich war ich nicht so hundertprozentig zufrieden.
svenw
2010-04-21, 20:13:41
Danke für die Info. Eine Lösung dürfte also nicht ganz trivial sein ohne Mitarbeit der Entwickler der Engines. Diese müßten die Zeit die die GPU braucht pro Frame braucht messen und die Daten dann entsprechend senden bzw etwas verzögern um eine gleichmäßige Verteilung der Frames zu erreichen.
y33H@
2010-04-21, 20:44:53
Das wäre über den Treiber möglich - aber auf Kosten der Fps. Und mit weniger Fps verkauft sich MGPU halt schlechter.
Watson007
2010-04-21, 20:54:52
tombman fragen...
Rampage 2
2010-04-21, 21:34:15
Das wäre über den Treiber möglich - aber auf Kosten der Fps. Und mit weniger Fps verkauft sich MGPU halt schlechter.
Gibt es überhaupts *seitens der GPU-Entwickler* die Chance, Mikroruckler bei Multi-GPU's vollständig und effektiv zu verhindern? Also ohne Framerate/Feature-Einbussen und ohne Verlust der BQ?
R2
Stefan 008
2010-04-21, 21:51:34
Was genau macht denn dann der Lucid chip auf dem MSI Big Bang Board ? der verhindert ja zum Teil das Mikroruckeln stark
Was genau macht denn dann der Lucid chip auf dem MSI Big Bang Board ? der verhindert ja zum Teil das Mikroruckeln stark
Lucid verwendet angeblich kein AFR, damit kann es natürlich auch kein dadurch bedingtes mikroruckeln geben.
Gibt es überhaupts *seitens der GPU-Entwickler* die Chance, Mikroruckler bei Multi-GPU's vollständig und effektiv zu verhindern?
Offenbar schon, Nvidia hat es zumindest mit 2 GPUs meistens halbwegs im Griff, bei ATI schaut es leider deutlich schlimmer aus.
y33H@
2010-04-21, 22:18:56
Wer sich die MGPU-Reviews der letzten Monate anschaut, wird bemerken, dass bei SLI die Skalierung im Mittel nicht so gut ist wie bei AMD, allerdings tendenziell weniger µRuckler. NV scheint (!) Fps zu opfern, um die Spielbarkeit zu erhöhen. Lars hat mal ein paar Details genannt, aber nur unter der Hand - man etwas via Treiber machen, ja.
Spasstiger
2010-04-21, 22:48:45
NV scheint (!) Fps zu opfern, um die Spielbarkeit zu erhöhen.
Ich muss wohl doch mal meinen Artikel fertigschreiben und das geplante Tool zur Frametime-Analyste erstellen. Im Bereich "Alternate Frame Rendering" scheint es noch viel Klärungsbedarf zu geben. :D
y33H@
2010-04-21, 22:49:31
Ich bin gespannt =)
deekey777
2010-04-21, 22:55:18
Die Zeit, die die CPU braucht, um die Daten für einen Frame vorzubereiten, ist wesentlich kürzer als die, die die GPU braucht, um einen Frame zu rendern.
Die Daten kommen also zu GPU 1, diese fängt an zu rendern; die CPU bereitet den nächsten Frame vor und schickt dessen Daten zu GPU 2, die auch zu rendern anfängt. Dann wartet die CPU, bis GPU 1 fertig ist (dauert eine Weile) und kann erst dann die Daten für den nächsten Frame an GPU 1 geben. Kurz darauf wird auch GPU 2 fertig uswusf.
Du hast dann stark verschiedene Zeiten zwischen den einzelnen Frames, also eine sehr kurze Zeit zwischen den Frames von GPU 1 und GPU 2 und eine recht lange Zeit zwischen denen von GPU 2 und GPU 1. Und das empfindet man wohl als Ruckeln.
-huha
Hier wird das anders erklärt:
http://www.rage3d.com/reviews/video/ati4870x2cf/index.php?p=2
Rampage 2
2010-04-21, 23:35:48
Offenbar schon, Nvidia hat es zumindest mit 2 GPUs meistens halbwegs im Griff, bei ATI schaut es leider deutlich schlimmer aus.
Ich spreche aber von *vollständig/radikal lösen* - also den Kerngrund lösen (die Hauptursache beheben) und so das Problem ohne irgendwelche Einbussen aus der Welt schaffen.
R2
Hier wird das anders erklärt
:confused: Da steht genau das, was huha auch schon geschrieben hat:
normally you'd expect 15ms between frames 1 and 2, but frame 2 is already finished, so it can be presented right away, immediately after frame 1 ... which is neat since it means a doubling of framerate, but there's a problem: GPU1 only started working on frame 3, so frame 3 won't be done immediately after frame 2 is presented ... it'll be done in 10ms, and here an inconsistency in time/frame shows up - this inconsistency is the much maligned micro-stuttering
And the cycle continues
Oder entgeht mir hier ein Detail?
@Spasstiger: Wenn du dir die Arbeit machst dazu einen Artikel zu schreiben würde es mich freuen, wenn du auch auf das Dilemma Triplebuffering & VSYNC im Zusammenhang mit MGPU und Microrucklern eingehen würdest. Ich glaube aths hat dazu vor Unzeiten mal was ganz Brauchbares abgeliefert:
http://www.3dcenter.org/artikel/was-heisst-vsync-und-wie-wendet-man-es
Allerdings betrifft dies nur SGPU-Hardware. Wär doch mal schön zu wissen, was passiert, wenn man auf einem 60HZ TFT bei aktivem VSYNC die nötigen 60 FPS trotz MGPU-Hardware knapp verfehlt.
Spasstiger
2010-04-22, 01:51:13
VSync + Triple-Buffering ist schwer zu untersuchen, weil Fraps hier keine sinnvollen Frametime-Messungen liefert. VSync + TB liefert eine andere Art von Mikroruckeln als Alternate Frame Rendering. Beim AFR kann es nämlich sein, dass zwei Frames gerendert werden, die nahezu identische Zeitpunkte im Spiel repräsentieren, was bei VSync + TB (@ Single-GPU) so nicht passieren kann.
Ein hübscher AFR-Test wäre mal eine Ingame-Uhr, die auch Milisekunden anzeigt. So könnte man einerseits testen, wie die Ausgabeverzögerung verteilt ist und andererseits wie die Renderzeitpunkte verteilt sind.
Mikroruckeln hat nämlich immer zwei Ursachen:
- Variation der Abstände zwischen den Renderzeitpunkten
- Variation der Ausgabeverzögerung
Die Ausgabeverzögerung kann man durch Verwendung eines Framelimiters harmonisieren, aber es hilft nicht viel, wenn die Abstände zwischen den Renderzeitpunkten variieren.
Ich spreche aber von *vollständig/radikal lösen* - also den Kerngrund lösen (die Hauptursache beheben) und so das Problem ohne irgendwelche Einbussen aus der Welt schaffen.
Man müsste eben AFR aufgeben. Das wird hoffentlich bald passieren, da es ohnehin auch andere Nachteile hat, die immer schlimmer werden.
Lenon
2010-04-22, 07:39:28
Ich bin was mGPU betrifft nicht so ganz belesen.
Bisher kenne SFR, AFR und Tiling(?).
Gibts da noch etwas anderes ?
[QUOTE=Lenon;7985336]
Bisher kenne SFR, AFR und Tiling(?).
/QUOTE]
AFR und SFR, Tiling ist nur eine Form von SFR.
andererGast
2010-04-22, 18:37:39
Gibts da noch etwas anderes ?
Ganz früher gab es mal das System auf den VooDoo-Karten. Das nannte sich afaik auch SLI, hat aber mit heutigem SLI nichts mehr zu tun. Wenn ich es richtig in Erinnerung habe, wurde ein Frame dort in gerade und ungerade Bildzeilen unterteilt. Während 3DfxCore1 die geraden Bildzeilen bearbeitet hat, hat 3DfxCore2 die ungeraden bearbeitet. Ich weiß leider nicht ob es tatsächlich so war und wie das ganze funktioniert hat. In jedem Fall war es wohl recht verlustreich, weil die Geometrie für jeden Frame zweimal berechnet werden mußte. Aber vielleicht irre ich mich da auch. In jedem Fall gab es auf den echten VooDoos seinerzeit keine Microruckler - da bin ich mir sicher. Das Ei hat nVidia ganz alleine ausgebrütet. Und ATi hat mit Crossfire eigentlich nur abgekupfert.
Vielleicht wird man irgendwann mal eine echte MGPU-Struktur entwickeln. Einfach zwei im wesentlichen unabhängige SGPU-Chips auf ein Board zu packen reicht nicht. Im Prinzip müßte ein vollwertiger Steuerchip dazu, der die beiden SGPUs 'entsynchronisiert'. Oder der Steuerchip müßte in der Lage sein, daß die beiden SGPUs tatsächlich und verlustfrei wieder am selben Frame rendern.
Im Prinzip ist das alles ein wahnsinniger Aufwand. Deswegen setze ich weiterhin voll und ganz auf SGPU in meinem PC. SLI und andere MGPU-Lösungen sind einfach nicht das gelbe vom Ei. Interessant würde ein solcher Aufbau für mich erst wieder werden, wenn die einzelnen GPUs im Verbund wieder unterschiedliche Aufgaben erfüllen. Möglicherweise tut sich da ja bald schon was (Cuda, PhysX, Stereoskopie etc. etc.). MGPUs zur Verdoppelung der Frameraten (ohne sichtbaren Effekt) ist in meinen Augen die totale Verschwendung einer interessanten Technologie.
VSync + TB liefert eine andere Art von Mikroruckeln als Alternate Frame Rendering.
Ja - alles in allem wäre dies in Kombination mit MGPU möglicherweise die Büchse der Pandora. Ich habe neulich mal gelesen, daß nVidia im Treiber inzwischen TB erzwingt, sobald VSYNC aktiviert wird, um den krassen Framedrop von 60 auf 30 bei DB auf TFTs zu verhindern. Damit wäre es also total sinnlos im Optionenmenu noch DB/TB einzustellen, da der nVidia-Treiber automatisch TB erzwingt sobald die Option VSync gewählt wurde. Oder irre ich mich da?
Pinoccio
2010-04-22, 18:47:58
Ein hübscher AFR-Test wäre mal eine Ingame-Uhr, die auch Milisekunden anzeigt.Auch für AF-und AA-Beobachtungen wäre eine simple Spielengine mal schön, da könnte man dann auch einen Uhr für sowas einbauen.
mfg
In jedem Fall war es wohl recht verlustreich, weil die Geometrie für jeden Frame zweimal berechnet werden mußte.
Damals hat die CPU doch auschließlich die Geometrie berechnet, oder?
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.