PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Mikroruckler - Die Umfrage


Spasstiger
2008-01-22, 22:28:46
Seid ihr Nutzer eines Multi-GPU-Systems (SLI/Crossfire) oder nutzt ihr VSync + Triplebuffering? Und ist euch dabei bereits trotz guter Framerate ein unrunde Spielgefühl aufgefallen, dass ihr mit nur einer GPU bzw. ohne VSync nicht habt?

Hier könnt ihr abstimmen.

Ich persönlich konnte noch kein Multi-GPU-System testen, aber die Mikroruckler bei VSync + Triplebuffering fallen mir deutlich auf. Ohne VSync laufen die Spiele wesentlich runder und trotz Tearing angenehmer fürs Auge.

Hinweis zur Umfrage: Die Umfrage ist zwar als Mehrfachumfrage ausgelegt, aber ich bitte euch, nur dort abzustimmen, wo ihr auch Erfahrungen sammeln konntet. Die Mikroruckler-Problematik durch das Alternate Frame Rendering bei SLI/Crossfire bitte ich auch getrennt von der Mikroruckler-Problematik bei VSync + Triplebuffering zu betrachten. D.h. wenn ihr keine Mikroruckler durch AFR habt, aber sehr wohl welche durch VSync + TB, dann bitte ich euch, das auch so differenziert in der Umfrage wiederzugeben.

HarryHirsch
2008-01-22, 22:50:56
[X] Crossfire: Mikroruckler messbar, aber nicht störend

Raff
2008-01-22, 22:52:42
[ ] Multichrome: Mikroruckler

30 Fps wirken je nach Spiel wie 15-20 ...

MfG,
Raff

Spasstiger
2008-01-22, 22:59:25
[ ] Multichrome: Mikroruckler

30 Fps wirken je nach Spiel wie 15-20 ...

MfG,
Raff
Oh, sorry, den Exoten hab ich ganz vergessen. Aber da es wohl nur eine handvoll User in diesem Forum mit Multichrome-Erfahrungen gibt, kann man diese paar Stimmen wohl vernachlässigen. ;)
Auf jeden Fall gut zu wissen, dass auch andere IHVs mit demselben Problem zu kämpfen haben.

tombman
2008-01-22, 23:02:52
[ ] Multichrome: Mikroruckler

30 Fps wirken je nach Spiel wie 15-20 ...

MfG,
Raff
Geile Meldung ;)

Man sieht, das ist ein plattformunabhängiges Problem ;)

Sonyfreak
2008-01-22, 23:36:37
[x] habe kein Multi-GPU-System, und spiele immer ohne VSync und Triple Buffering

Daher konnte ich dahingehend keinerlei Beobachtungen machen.

mfg.

Sonyfreak

Gast
2008-01-23, 07:59:16
[CF] Microruckler Messbar, im Spiel merkt man nichts davon.

[SLI] Microruckler Messbar, merkt man aber in manchen Spielen auch nicht, gibt auch welche wo man es sehr doll merken tut.

PS: die Frametimes sind nicht so weit auseinander von CF wie von meinen 2x 8800 GTX.

PHuV
2008-01-23, 11:19:41
[x] SLI: Mikroruckler bemerkbar und störend, und mich stört es. Ich habe mich immer gewundert, warum manchmal trotz SLI und entsprechenden Frames um die 30 immer das flüssige Gefühl fehlte, dank tombman weiß ich es nun. Es ist eigentlich ein Skandal, daß ATI und Nvidia dazu noch nicht gesagt haben, aber angeblich von dem Problem wissen (nach Computerbase, die es nicht mal für nötig hielten, Tombman zu erwähnen).

Cubitus
2008-01-23, 11:24:17
[x] Ja bemerkbar und teilweise störend.

Etwas Abhilfe schafft die Fummelei an den SLI Values, Vsync, da meistens dann ein Framelimitierer aktiviert wird und eben Ludis Tool (leider nur unter DX9)

2B-Maverick
2008-01-23, 11:51:38
[x] VSync und keine Mikroruckler...

gehe ich richtig in der Annahme, dass bei VSync ON der TB immer genutzt wird? (ne ATI 1900GT)
Ohne VSync ist mein Flugsimulator (Condor) nicht zu ertragen.... hmmm...

CU
Markus

malle
2008-01-23, 16:48:43
Gelten solche Ruckler auch für Videos?

2B-Maverick
2008-01-23, 17:08:08
Gelten solche Ruckler auch für Videos?

Ruckler bei Videos haben ganz andere Ursachen (24 hz / 25 Hz Problematik z.B.).
Daher: nein... hier nicht gefragt...

CU
Markus

Spasstiger
2008-01-23, 21:21:14
[x] VSync und keine Mikroruckler...

gehe ich richtig in der Annahme, dass bei VSync ON der TB immer genutzt wird? (ne ATI 1900GT)
Ne, das ist nur bei GeForce-8-Karten der Fall. Bei ATI musst du Triplebuffering im Spiel aktivieren oder per Tools erzwingen. Ich empfehle hierfür D3DOverrider. Bei OpenGL kannst du einfach Triplebuffering per Treiberpanel erzwingen.

Grestorn
2008-01-24, 07:42:32
Ich habe
[x] SLI: Mikroruckler bemerkbar, aber nicht störend

und

[x] VSync + TB: Mikroruckler bemerkbar, aber nicht störend

gewählt. Ganz genau passt die Antwort nicht. Man müsste sagen:

Nur in bestimmten Fällen merkt man diese Effekte negativ. In der mit Abstand größeren Menge der Fälle ziehe ich sowohl VSync+TB bzw. SLI dem Pendant ohne diese Features deutlich vor.

Es gibt aber immer Ausnahmen. Crysis z.B. ist für mich mit VSync + SLI (TB unbekannt) unspielbar, ohne VSync ist SLI perfekt in dem Spiel.

Bei Bioshock stört dagegen SLI mehr als es bringt.

Man muss sich derzeit tatsächlich jedes Spiel einzeln anschauen.

Ich wünschte mir, es gäbe endlich eine "Smoothen Frame distribution"-Option im Treiber.

Gast
2008-01-24, 12:02:28
Hallo wan tretten diese microruckler auf ? ich habe immer VSync aus. Ist es dan nicht mehr bemerkbar oder ist es unterschiedlich ?

Mfg Mike

Banshee18
2008-01-24, 13:04:44
Hallo wan tretten diese microruckler auf ? ich habe immer VSync aus. Ist es dan nicht mehr bemerkbar oder ist es unterschiedlich ?

Mfg Mike
Mit SLI oder vSync + Triplebuffering. Richtig spürbar ist es außerdem nur mit wenig fps.

jojo4u
2008-01-24, 15:31:57
Gibt's irgendwo eine technische Erklärung zu Vsync+TB und Mikrorucklern? Bis jetzt hatte ich gedacht das ist das Nonplusultra an Bildqualität.

Spasstiger
2008-01-24, 15:49:00
Gibt's irgendwo eine technische Erklärung zu Vsync+TB und Mikrorucklern? Bis jetzt hatte ich gedacht das ist das Nonplusultra an Bildqualität.
Mit VSync sind ja nur festgelegte Stufen für die Frametimes möglich, z.B. bei 60 Hz Wiederholfrequenz nur 16,67 ms, 33,33 ms, 50 ms, 66,67 ms, usw.
Wenn du mit VSync ohne Triplebuffering spielst, werden meist viele Bilder hintereinader für jeweils 33,33 ms angezeigt, dann einige für 50 ms, dann wieder einige für 33,33 ms, vielleicht auch mal ein paar zu je 16,67 ms. Für die Framerate bedeutet das z.B. eine 4 Sekunden lang 30 fps, dann zwei Sekunden lang 20 fps, dann eine Sekunde lang 30 fps und anschließend 60 fps.
Mit VSync + Triple Buffering springen die Frametimes nun ständig. Um z.B. auf 40 fps zu kommen, wird ein Frame für 16,67 ms angezeigt, der nächste für 33,33 ms, der nächste wieder für 16,67 ms, der nächste für 33,33 ms, usw.
Dies empfindet man als ruckelig, obwohl im Schnitt 40 fps rauskommen.

Ohne VSync würden in dem Fall alle Bilder für ungefähr 25 ms angezeigt werden (wobei sich die Bilder halt auf mehrere Bildschirmframes aufteilen, das berühmte Tearing).

Skinner
2008-01-26, 13:55:57
[x] Crossfire: Mikroruckler bemerkbar, aber nicht störend

Hab die Ruckler bisher nur bei Crysis festgestellt. Denke/Hoffe aber, das sich das mit neuen Treibern bessern wird. Crysis hat da eh eine komplette eigendynamik bei Crossfire im Moment :D

Aquaschaf
2008-01-26, 14:19:07
VSync + TB: ja, öfters störend.

Spasstiger
2008-01-26, 15:54:06
Die Problematik der Mikroruckler ist nach den bisherigen Ergebnissen doch sehr real und praxisrelevant.
Von 16 SLI-Usern empfinden 10 das Mikroruckeln als störend.
Von 9 Crossfire-Usern empfinden 6 das Mikroruckeln als störend.
Von 19 Usern, die VSync + TB fahren, empfinden 7 das Mikroruckeln als störend.

Bei Multi-GPU scheint es also wirklich ein großes Problem zu sein. Wird vielleicht mal Zeit für einen 3DC-Artikel, der sich mit dem Problem und Lösungsansätzen auseinandersetzt. Vielleicht gibts dann bei Geizhals bei der Radeon HD3870 X2 und der GeForce 9800 GX2 wieder einen netten Link zu 3DCenter.de. ;)

MarcWessels
2008-01-26, 16:49:33
[x] habe kein Multi-GPU-System, und spiele immer ohne VSync und Triple Buffering

Daher konnte ich dahingehend keinerlei Beobachtungen machen.Dafür aber mit derbem Tearing! :eek:

OT-> Also mein Ziel war es ja, als ich noch mit dem PC gespielt habe - dauerhafte 60fps zu erreichen. Da dies aber bei absolut neuen Spielen niemals durchgängig klappen kann, habe ich TB eingesetzt, um zumindest Ausreißer etwas abzufangen.

Mit anderen Worten empfinde ich 30fps bei VSync + DB als deutlich störender als 52fps bei VSync + TB.

Auf die Idee, VSync Off außerhalb von Benchmarks zu verwenden, wäre ich nie gekommen - sieht nunmal furchtbar aus.

Spasstiger
2008-01-26, 17:03:17
Ich bekomm halt bei vielen Games Kopfschmerzen mit VSync + Triplebuffering, weil der ganze Bildablauf stottert und nicht zum Input passt. Tearing bin ich einigermaßen gewohnt, schön ist es natürlich aber auch nicht.
Am Besten ist es immer noch, auf einem CRT mit 100 Hz und mehr zu zocken, da fällt einem das Tearing beim Zocken kaum noch auf.

Gast
2008-01-26, 17:15:17
Ich bekomm halt bei vielen Games Kopfschmerzen mit VSync + Triplebuffering, weil der ganze Bildablauf stottert und nicht zum Input passt. Tearing bin ich einigermaßen gewohnt, schön ist es natürlich aber auch nicht.
Am Besten ist es immer noch, auf einem CRT mit 100 Hz und mehr zu zocken, da fällt einem das Tearing beim Zocken kaum noch auf.
Derbes Tearing hat man bei 65 Hz am TFT, eigentlich bei jeder Drehung. Da sieht's ein Blinder mit nem Krückstock. Bei 75 Hz ist es imho schon erträglich, fällt eigentlich gar nicht mehr auf, wenn man nicht explizit drauf achtet. CRT mit 100 Hz und mehr ist natürlich noch besser. Aber bei den großen WS TFTs ist ja momentan 65 Hz das höchste der Gefühle, da führt an Vsync kein Weg vorbei.

Spasstiger
2008-01-26, 17:16:48
da führt an Vsync kein Weg vorbei.
Aber nur, wenn man durchgehend 60 fps hat. Sonst läuft es ziemlich unrund.
Ohne VSync wird die Bewegung der Maus auch bei niedrigen Frameraten analog umgesetzt. Mit VSync und vor allem noch zusätzlich aktiviertem Triplebuffering ist es eine abgehackte, stotternde Umsetzung, wie eine Analog-Digital-Wandlung mit zu geringer Abtastrate (quasi Aliasing der Eingabe).

Auch eine Lösung ist es unter Verwendung von VSync, wenn man die Framerate auf 30 fps begrenzt (und man auch nicht drunter fällt). Das ist aber nur dann eine gute Lösung, wenn das Spiel echtes Motionblur rendert. In Zukunft wird das wohl häufiger der Fall sein.

MarcWessels
2008-01-27, 00:13:56
Am Besten ist es immer noch, auf einem CRT mit 100 Hz und mehr zu zocken, da fällt einem das Tearing beim Zocken kaum noch auf.Dafür passt dann die Framerate wieder nicht zur Bildwiederholfrequenz - muss 1:1 passen.

Nasenbaer
2008-01-27, 19:00:13
Die meisten Spiele erlauben doch gar nicht die Einstellung von TB und für Direct3D kann mans doch gar nicht erzwingen oder?

Spasstiger
2008-01-27, 19:05:03
Die meisten Spiele erlauben doch gar nicht die Einstellung von TB und für Direct3D kann mans doch gar nicht erzwingen oder?
Auf GeForce-8-Karten ist Triple-Buffering mit VSync automatisch aktiv und bei allen anderen Karten kann mans mit D3DOverrider erzwingen (ist im Rivatuner-Ordner enthalten).

san.salvador
2008-01-27, 19:06:10
Klar kann man das, bei Nvidia ist es mit Vsync immer aktiv.

€dit: Verdammt! :usad:

Nasenbaer
2008-01-27, 19:08:38
Auf GeForce-8-Karten ist Triple-Buffering mit VSync automatisch aktiv und bei allen anderen Karten kann mans mit D3DOverrider erzwingen (ist im Rivatuner-Ordner enthalten).
Achso das wusst ich gar nicht. Im ATi CCC konnte man es damals nur für OpenGL aktivieren und deswegen dacht ich, dass es da ne technische Hürde gibt die das verhindert.
Thx!

@Topic:
Dann hab ich auch welche - jedenfalls bei NFS - Pro Street, mag aber auch am Spiel liegen.

pest
2008-01-27, 19:11:46
Die Umfrage könnte genauso heißen: "Merkt ihr wenn die Framerate auf < 30 fällt?" :rolleyes:

Spasstiger
2008-01-27, 19:23:09
Die Umfrage könnte genauso heißen: "Merkt ihr wenn die Framerate auf < 30 fällt?" :rolleyes:
Hm? Mikroruckler merkt man auch bei durchschnittlich 50 Bildern pro Sekunde.

pest
2008-01-27, 19:32:48
Hm? Mikroruckler merkt man auch bei durchschnittlich 50 Bildern pro Sekunde.

Sorry , meinte mit Framerate nich unbedingt Frames per Second, war missverständlich


Die Umfrage könnte genauso heißen: "Merkt ihr wenn die Minframes auf < 30 fallen?"


besser?

Spasstiger
2008-01-27, 19:37:31
besser?
Nein.
Es geht um die Frametimes. Du musst fragen: "Merkt ihr, wenn die Frametimes springen, z.B. ein Frame für 16 ms dargestellt wird, der nächste für 33 ms und der nächste wieder für 16 ms?"

pest
2008-01-27, 20:56:36
Nein.
Es geht um die Frametimes. Du musst fragen: "Merkt ihr, wenn die Frametimes springen, z.B. ein Frame für 16 ms dargestellt wird, der nächste für 33 ms und der nächste wieder für 16 ms?"

Wieso, das sind minimum-Zeiten. Es ist doch egal ob es einmal 33ms dauert oder die ganze Zeit, es stört. :confused:

Piffan
2008-01-28, 23:06:29
Interessanter Thread. Aber wie zum Teufel kommt ihr auf das Brett, dass bei Triple- Buffering die Frametimes ständig unterschiedlich sind?

Afaik entstehen die Sprünge bei Vsync on OHNE TB. Genau dafür ist TB ja gedacht, um das Rendering von der Bildausgabe unabhängig zu machen. Und zwar bei FPS- Werten, die UNTERHALB der Vsync- Zahl liegen.

Kann sein, dass ich schief liege, aber diese Ruckler bei geringen FPS- Werten unterhalb der Monitorfrequenz entstehen bei VsyncOn OHNE TB. Oder was jetzt? :confused:

Oder anders gefragt: Welchen Sinn hat denn dann TB, wenn es mit doch ruckelt?

Gast
2008-01-28, 23:42:44
Interessanter Thread. Aber wie zum Teufel kommt ihr auf das Brett, dass bei Triple- Buffering die Frametimes ständig unterschiedlich sind?

Afaik entstehen die Sprünge bei Vsync on OHNE TB. Genau dafür ist TB ja gedacht, um das Rendering von der Bildausgabe unabhängig zu machen. Und zwar bei FPS- Werten, die UNTERHALB der Vsync- Zahl liegen.

Kann sein, dass ich schief liege, aber diese Ruckler bei geringen FPS- Werten unterhalb der Monitorfrequenz entstehen bei VsyncOn OHNE TB. Oder was jetzt? :confused:

Oder anders gefragt: Welchen Sinn hat denn dann TB, wenn es mit doch ruckelt?
Afaik verzögert TB nur die Bildausgabe. Das dürfte man nur merken, wenn man auch einen Input gibt (Maus, Tasta).
Die Mikroruckler sind aber optischer Natur, das heißt auch ein außenstehender Beobachter nimmt eine choppy Bildabfolge wahr.

Spasstiger
2008-01-28, 23:48:37
Mit VSync + Triplebuffering und 60 Hz werden Frames für jeweils genau 16,67 ms, 33,33 ms, 50 ms, 66,67 ms, usw. dargestellt. Framedauern von 20 ms, 25 ms oder 27 ms sind dabei prinzipbedingt nicht möglich.
Sollen 40 Bilder in der Sekunde dargestellt werden, werden also nicht alle Bilder für 25 ms angezeigt, sondern jeweils im Wechsel ein Bild für 16,67 ms und ein Bild für 33,33 ms.
Zusätzliche Verzögerungen gegenüber VSync + Doublebuffering ergeben sich bei Triplebuffering allerdings nicht, zumindest keine notwendigen (keine Ahnung, ob der Grafiktreiber da noch was reinpfuscht, z.B. das Prerenderlimit höhersetzt).

Piffan
2008-01-29, 00:08:10
Mit VSync + Triplebuffering und 60 Hz werden Frames für jeweils genau 16,67 ms, 33,33 ms, 50 ms, 66,67 ms, usw. dargestellt. Framedauern von 20 ms, 25 ms oder 27 ms sind dabei prinzipbedingt nicht möglich.
Sollen 40 Bilder in der Sekunde dargestellt werden, werden also nicht alle Bilder für 25 ms angezeigt, sondern jeweils im Wechsel ein Bild für 16,67 ms und ein Bild für 33,33 ms.
Zusätzliche Verzögerungen gegenüber VSync + Doublebuffering ergeben sich bei Triplebuffering allerdings nicht, zumindest keine notwendigen (keine Ahnung, ob der Grafiktreiber da noch was reinpfuscht, z.B. das Prerenderlimit höhersetzt).


Danke für die Erklärung. Also hat es keinen Einfluss aufs Gameplay, martert höchstens die Augen.....

Weil ich eh nur ohne Vsync Zocke und das Tearing nicht mehr wahrnehme, kann ich mit dem Problem durchaus leben. Ausnahme war DOOM 3: Aufgrund flackernder Lichtquellen ist das Tearing eine Qual in diesem Spiel.

Gast
2008-01-29, 00:16:43
Mit VSync + Triplebuffering und 60 Hz werden Frames für jeweils genau 16,67 ms, 33,33 ms, 50 ms, 66,67 ms, usw. dargestellt. Framedauern von 20 ms, 25 ms oder 27 ms sind dabei prinzipbedingt nicht möglich.
Sollen 40 Bilder in der Sekunde dargestellt werden, werden also nicht alle Bilder für 25 ms angezeigt, sondern jeweils im Wechsel ein Bild für 16,67 ms und ein Bild für 33,33 ms.

Ganz genau, und hier liegt auch das Problem bei TFTs, die nur 60Hz können (bei Röhren @60Hz ist es natürlich genauso). Mit Vsync braucht man immer möglichst über 60fps, denn wenn die fps mal knapp unter 60 fallen gibts sofort vereinzelt Frames mit 33,33ms-Frametime, welche 30fps entsprechen. Das gibt ein übles gezucke/ geruckel, wenn man zwischen 30-60fps operiert! (Ständig wechseln Frames @16,67ms-Frametime mit Frames @33,33ms-Frametime). Tjo, ohne Vsync gibts leider wieder übles Tearing. :(

Mögliche Lösungen des Problems:

1. Höhere Wiederholfrequenz, möglichst 90Hz+ und ohne Vsync zocken (verringert das Tearingproblem schon ganz gut).

2. Keine feste Wiederholfrequenz + Sync mit Monitor! Monitor macht immer genau dann ein Refresh, wenn die Graka ein neues Bild fertig hat und liefert. (Das Ganze könnte z.B. bei 60Hz gekappt werden, falls Monitor nicht mehr schafft).

Piffan
2008-01-29, 00:52:44
Ganz genau, und hier liegt auch das Problem bei TFTs, die nur 60Hz können (bei Röhren @60Hz ist es natürlich genauso). Mit Vsync braucht man immer möglichst über 60fps, denn wenn die fps mal knapp unter 60 fallen gibts sofort vereinzelt Frames mit 33,33ms-Frametime, welche 30fps entsprechen. Das gibt ein übles gezucke/ geruckel, wenn man zwischen 30-60fps operiert! (Ständig wechseln Frames @16,67ms-Frametime mit Frames @33,33ms-Frametime). Tjo, ohne Vsync gibts leider wieder übles Tearing. :(

Mögliche Lösungen des Problems:

1. Höhere Wiederholfrequenz, möglichst 90Hz+ und ohne Vsync zocken (verringert das Tearingproblem schon ganz gut).

2. Keine feste Wiederholfrequenz + Sync mit Monitor! Monitor macht immer genau dann ein Refresh, wenn die Graka ein neues Bild fertig hat und liefert. (Das Ganze könnte z.B. bei 60Hz gekappt werden, falls Monitor nicht mehr schafft).


Ja klar, und beim Röhren CRT leuchtet dann die ganze Zeit der Phosphor bis zum nächsten Refresh oder was? Flimmerorgie ahoi. :tongue:

So was könnte klappen bei einem TFT, sprich Refresh an den Rendervorgang zu koppeln.


Edit: Das Geholpere wird ja dank TB verhindert, nur die Frametimes variieren. Das habe ich heute gelernt. Für einen Laien doch schon tiefschürfendes Wissen....:tongue:

Gast
2008-01-29, 00:55:05
Ja klar, und beim Röhren CRT leuchtet dann die ganze Zeit der Phosphor bis zum nächsten Refresh oder was? Flimmerorgie ahoi. :tongue:

So was könnte klappen bei einem TFT, sprich Refresh an den Rendervorgang zu koppeln.

Wo ist das Problem? Für CRTs geht halt nur Lösung 1 und bei TFTs würde theoretisch Lösung 2 machbar sein! :)

Gast
2008-01-29, 01:18:56
Edit: Das Geholpere wird ja dank TB verhindert, nur die Frametimes variieren. Das habe ich heute gelernt. Für einen Laien doch schon tiefschürfendes Wissen....:tongue:

Eben nicht!!! Durch den TB entsteht es ja erst! Ohne TB wird bei 60Hz mit Vsync z.B. alles zwischen 30,001fps -59,999fps auf 30fps gekappt und ist somit ruckelfrei (es wird jeder Frame genau doppelt dargestellt).

So. Angenommen Du hast 60Hz Vsync und TB und die Graka bringt genau 40fps. Dann wird abwechseln ein Frame einmal und ein Frame doppelt dargestellt. Anders geht es nicht. Es enstehen hier Kadenzen von 16,7ms-33,3ms-16,7ms-33,3ms...usw. -> Es zuckelt vor sich hin! Wenn jetzt nicht genau 40fps anliegen, sondern irgendwas zwischen 30,001fps - 59,999fps hast Du immer total unregemäßige Kadenzen, z.B. 16,7ms-33,3ms-33,3ms-16,7ms-33,3ms-16,7ms-16,7ms...usw. -> Es zuckelt und ruckelt, und auch noch total unregelmäßig, da die Fps ja auch nie konstant sind.

Piffan
2008-01-29, 01:27:22
Eben nicht!!! Durch den TB entsteht es ja erst! Ohne TB wird bei 60Hz mit Vsync z.B. alles zwischen 30,001fps -59,999fps auf 30fps gekappt und ist somit ruckelfrei (es wird jeder Frame genau doppelt dargestellt).

So. Angenommen Du hast 60Hz Vsync und TB und die Graka bringt genau 40fps. Dann wird abwechseln ein Frame einmal und ein Frame doppelt dargestellt. Anders geht es nicht. Es enstehen hier Kadenzen von 16,7ms-33,3ms-16,7ms-33,3ms...usw. -> Es zuckelt vor sich hin! Wenn jetzt nicht genau 40fps anliegen, sondern irgendwas zwischen 30,001fps - 59,999fps hast Du immer total unregemäßige Kadenzen, z.B. 16,7ms-33,3ms-33,3ms-16,7ms-33,3ms-16,7ms-16,7ms...usw. -> Es zuckelt und ruckelt, und auch noch total unregelmäßig, da die Fps ja auch nie konstant sind.

Mit dem Holpern meinte ich was anderes: Sobald ich die Vsync unterschreite, springt die FPS- Zahl auf den halben Wert von Vsync. Unterschreite ich den Wert wieder, dann springt sie auf ein Drittel.... Es gibt also keine Mikroruckler, sondern unsägliche Makro- Sprünge in der FPS- Zahl, ergo massive Störungen des Gameplays bei FPS- Werten unterhalb von Vsync.

Ich kenne das Problem der Ruckler bei Vsync und TB nicht, aber es ist rein optisch. Die Engine arbeitet smooth und das Gameplay ist sauber.

MadManniMan
2008-01-29, 06:34:46
Ich kenne das Problem der Ruckler bei Vsync und TB nicht, aber es ist rein optisch. Die Engine arbeitet smooth und das Gameplay ist sauber.

Hmnjein - denn Du an Deiner Maus arbeitest ja (idealerweise) schön analog weiter, während die Übersetzung auf dem Monitor stets und ständig in anderen Abständen daherkommt.

seahawk
2008-01-29, 07:02:38
Kann man imho sehr gut bei FPS mit einer brauchbaren Sniper Umsetzung sehen. Stelle ich BF:2 durch hohe AA-Settings in den Bereich von 60FPS unterschritten werden, aktiviere VS und TB, dann spürt man wie es schwere wird einem seitlich zum Schützen laufendes Ziel sauber zu verfolgen.

Grestorn
2008-01-29, 07:19:12
Hmnjein - denn Du an Deiner Maus arbeitest ja (idealerweise) schön analog weiter, während die Übersetzung auf dem Monitor stets und ständig in anderen Abständen daherkommt.

Wenn die Abstände aber korrekt mit dem Zeitablauf korellieren (sprich: Die Input-Verzögerung konstant bleibt) und einen Maximalwert nicht übersteigen, dürften diese Schwankungen eigentlich nicht wahrnehmbar sein.

Das werden sie erst, wenn einzelne Abstände zu lange werden.

Deswegen stört auch das VSync / TB Problem bei Frameraten von mehr als 30 fps nicht so sehr. Bei SLI, speziell wenn die Frameraten im Bereich von 30 fps oder darunter liegen, wird es aber eben doch spürbar und beginnt zu stören.

Die Ungleichmäßigkeiten durch VSync/TB bei Frameraten unter 30 fps sind - im Gegensatz zu SLI - wiederum nicht so deutlich, da die Schwankungen verglichen mit der Zeit pro Frame vergleichsweise gering sind. Bei SLI können die Schwankungen dagegen theoretisch bis nahezu 100% betragen.

pervert
2008-02-01, 23:57:47
Kann man imho sehr gut bei FPS mit einer brauchbaren Sniper Umsetzung sehen. Stelle ich BF:2 durch hohe AA-Settings in den Bereich von 60FPS unterschritten werden, aktiviere VS und TB, dann spürt man wie es schwere wird einem seitlich zum Schützen laufendes Ziel sauber zu verfolgen.

Ich nehme an, Du meinst jetzt speziell Nvidia Hardware?

Dann stell mal bitte das Prerender Limit auf "1", dann hast Du frühestens wieder ab 30fps solche Probleme, bzw das gleiche Feeling bei 20fps wie sonst bei 60!

Und/oder beim TFT Overdrive abschalten.

Gast
2008-02-02, 02:19:39
3870 x2 - teilweise störende mikroruckler

Sabber...
2008-02-12, 00:32:17
Sehr schön eure umfrage !
Aber mich würde brennend interessieren ob ihr mit eurer gespaltenen Meinung einem non SLI o. CF nutzter zu einem solchem System ratet,oder ist es noch eine nervtötende Angelegenheit die störend ist weil nicht beseitigbar,oder nur mit vielen Einstellungen und Bastelei zu einem einigermaßen guten Ergebnis zu bekommen ?
Mir geht es darum bekommt Nvidia und AMD das Problem endlich in den griff? Denn in zu kunft soll immer mehr vom multi-GPU Karten auf den Markt kommen.

Danke euch allen :)

Gast
2008-02-12, 13:31:15
Ob Nvidia und AMD dieses Problem in den Griff bekommen ist eine Frage es willens und des Nutzens.

Bildfolgen können bei SLI/CF nach oben und nach unten ausbrechen. Und das ist je nach Hardwarekombi, Spiel und Profileinstellung mal mehr, mal weniger schlimm.

Subjektives Empfinden spielt dabei genauso eine eine wichtige Rolle, wie die Reaktionszeit des TFTs. Denn selbst ein einzige Frame, was eine Störung (z.b.: 40ms wegen Berechnungsfehler statt 10ms) hat wird als Microruckler wargenommen.

Eine Lösung wäre eine Frametime begrenzung, die nicht nur nach unten, sondern auch nach oben Begrenzt z.b.: bei Angestrebten 100FPS: füheste Bildfolge nach 10ms und späteste Bildfolge nach 15ms, sonst überspringe Frame.
Bei 1000ms (also 1s) bewegt sich das Bild dann zwischen 100FPS bis 66FPS und im schlimmstenfall bei 50FPS.

Und letzteres ist das Problem: im extremfall würde jedes Bild der zweiten GPU übersprungen, weil es zu lange braucht, also SLI/CF total nutzlos.

Die Geschwindigkeit eines SLI/CF würde dann sogar langsamer sein als eine Singel.
Genau aus dem Grund hat man schon von Splitscreenrendering abstand genommen und komplett zu AFR gewechselt (CF läuft ja nur noch im AFR Modus).

SLI würde sich so nicht mehr verkaufen lassen.

Die Frage wird sein, ob die Entwickler neue Alternativen des Renderings finden werden oder eine dynamische Anpassung der Syncronisation mit Hauptziel auf Gleichverteilung der Frames in 1s.

Wegen SLI/CF ja nein Frage will ich nicht beantworten. Bei meiner Kaufentscheidung stand ich zwischen der Wahl zwischen ruckelnden Bildern oder Mikroruckler :)

Gast
2008-02-12, 13:46:04
Eine dynamische anpassung würde auch einfach umzusetzen sein.
Ein Instanz sich merkt, wieviel Bilder der zweiten (potenziel langsameren Graka) nicht in dem gewünschten Intervall dargestellt wurden (z.b. über eine Zeit t= 1000ms)

Sollten z.b. 50 % der Bilder der zweiten Graka nicht innerhalb von 15ms auf dem Schirm gelandet sein, dann wird die Ziel-FPS automatisch nach unten korrigiert. Ziel 100FPS auf 60FPS.
Bei 60 FPS hat ein Bild 16,6ms Zeit bis zur Ausgabe. Neues Fenster könnte dann bei : 16ms bis 18ms liegen.

Sabber...
2008-02-12, 22:26:19
Ihr habt gut reden aber warum bekommen die von AMD und Nvidia das Problem nicht in den griff?
Ist es den so schwer ? Wir können m
Menschen und sogar Affen.... auf den Mond schießen bekommen es aber nicht in den griff zwei GPUs zu synchronisieren.

Nasenbaer
2008-02-13, 10:07:56
Warum ist eigentlich das Splitscreen-Rendering für dieses Problem genauso schlecht geeignet? Naja, dass ne horizontale Unterteilung des Bildes keine gleichmäßige Lastverteilung erreicht mag mir ja einleuchten aber man könnte das Bild ja genausogut senkrecht teilen - dürfte ja nun nicht der weltbewegende Unterschied sein in der Umsetzung.

Gast
2008-02-13, 13:12:54
Naja eigentlich haben AFR und SFR Vor/nachteile.

Nachteil AFR:
Wenn die GPU1 Ergebnisse benötigt, die erst von der GPU0 zur Verfügung gestellt werden müssen (z.b.: Render to Textur Befehle - die immer häufiger zum einsatz kommen und mitschuld an Microrucklern sind). Denn die Frage ist, wie lange läst man die zweite Graka auf Daten der ersten warten?

Nachteil SFR:
Langsamer: jeder GPU müssen dieselben Geometriedaten vorliegen, damit sie wissen, wo welchen Objekt sich im Bild befindet. Ergo wird nur die Pixel-Berechnung beschleunigt, wärend der Vertex-Shader genauso langsam wie auf einer Singel arbeitet.

Kompliziertes Verfahren: (Load-balance nötig, wenn es zu ungleichen Berechnungsaufwand eines Bildes kommt: oben nur Himmel, untere Bildhälfte viel Action)

Der Effekt von SLI kann dabei gegen 0 gehen. Und in der Realität war der Gewinn so gering, das man davon abgekommen ist und es nur noch als Kompatibilitätsmodus beläßt.


Quad SLI arbeiten z.b. nur im AFR of SFR, bei dem beide Verfahren zum einsatz kommen.

Die Probleme sind eigentlich die gleichen wie bei Cpus das Pipeline-Problem. Wörter wie Sprungvorhersage etc. sind jedoch bei Bildern nicht zu gebrauchen - wer will schon, das eine GPU1 errät welche Berechung die GPU0 durchgeführt haben könnte.

http://www.computerbase.de/artikel/hardware/grafikkarten/2006/test_nvidia_geforce_7950_gx2_quad-sli/3/

Wegen Mikroruckler:
Ein Tip der ein wenig Verbesserung schafft: Threadoptimierung auf on.

Gast
2008-02-13, 13:15:07
Zusatz: deswegen hat Quad SLI kein nutzen und bei Tripel SLI, die dritte GPU zur Physikberechung eingesetzt.

AnarchX
2008-02-13, 13:26:41
4-Way-AFR ist in den aktuellen 173er-Betatreibern schon vorhanden.;)

Gast
2008-02-14, 13:17:16
Soweit ich weiß offiziell nur für Vista, weil prerender auf 4 muß, MS aber nur eine freigabe für vista gibt.

Kann erstmal nur von nvidia sprechen:
Bei D3D wird 4-way AFR nicht genutzt. Ausschliesslich SFR & AFR. Soweit ich weiß. 4-way AFR geht erstmal nur in OpenGL.

Kannst mich aber auch korrigieren.

Gast
2008-02-17, 16:28:45
Hm, konnte bei meinem Multichrome-System bislang noch keine Mikroruckler festellen... (basiert ja auch auf AFR & SFR)

Raff
2008-02-17, 16:29:51
Hm, konnte bei meinem Multichrome-System bislang noch keine Mikroruckler festellen... (basiert ja auch auf AFR & SFR)

Du musst nur mal den 3DMark05 anwerfen. Ganz evil. Makro- und Mikroruckler kombiniert.

MfG,
Raff

Thunder99
2008-02-18, 20:47:48
Wie schaut das Thema bei der guten Voodoo 5 bzw 6 aus, wo ja 2-4 die Arbeit verrichten?
Ist das ähnlich aufgebaut, oder ganz anders damit die Grafkchips zusammenarbeiten können.

Gibt es da überhaupt Microruckler?

san.salvador
2008-02-18, 20:49:09
Da die gemeinsam an einem Bild arbeiten (Vodoo 5/6), gibt es das Problem dort nicht.

Raff
2008-02-18, 22:41:06
Yep. Bei der V5 6000 ist alles flutschig. Und damit ist auch fast bewiesen, dass es an AFR liegt.

MfG,
Raff

Grestorn
2008-02-19, 06:49:24
Yep. Bei der V5 6000 ist alles flutschig. Und damit ist auch fast bewiesen, dass es an AFR liegt.


Das muss man nicht beweisen, das ist absolut klar wenn man sich überlegt was AFR ist und wie die ungleiche Verteilung der Frames zustande kommt.

Dennoch kein Argument gegen AFR, weil ich weiterhin der festen Überzeugung bin, dass das Problem vergleichsweise leicht in den Griff zu bekommen wäre. Nur muss wohl noch erst der Druck für die Treiberhersteller steigen, damit da auch was passiert.

tombman
2008-02-19, 08:37:10
Ich war ja länger gebanned, aber Saaya@ XS.org hat mich auf was gebracht. Er meinte nämlich, daß die reine Verschiebung des frames nix bringen würde, also so wie es der Ludi limiter macht.
Denn der INHALT des verschobenen Bildes ist ja immer noch der aus der zu frühen Zeit!! Also wenn die Kadenz zb 10-50 ist, und man einfach 20ms bei den 10ms wartet, dann hat man zwar 30-30, aber der INHALT des Bildes vom ersten 30er wäre immer noch der vom 10er!!
Dh man würde das erste Bild, bzw die Information des ersten Bildes, zu einem
falschen Zeitpunkt sehen.

Vermutlich war das der Grund warum mir das ganze auch MIT dem Limiter nicht perfekt flüssig vorkam. Es glättet die ganze Sache zwar, aber man würde sowas wie einem 3:2 pulldown analog zur Filmthematik bekommen.

Vielleicht ist das ein Grund, warum das Problem von Nvidia und co noch nicht gelöst wurde?

Das heißt also, nochmal von vorn: die cpu rechnet "viel zu schnell" (weil sie so leistungsfähig ist) zwei frames fix fertig für die beiden gpus vor, und schickt jeder gpu ihren frame. Dh, gpu1 bekommt den frame bei Zeitpunkt 10ms und gpu2 bei Zeitpunkt 20ms, also nur 10ms Unterschied. Jetzt braucht aber jede gpu für ihren frame 60ms, sprich die cpu muß auf die gpus warten. Den ersten frame sehen wir also bei Zeitpunkt 70ms (10ms cpu + 60ms gpu), den zweiten bei Zeitpunkt 80ms (20ms cpu + 60ms gpu).
80ms minus 70ms = 10ms Unterschied zwischen frame 1 und frame 2, also das was wir erstmals SEHEN. Wir sehen also die ersten beiden frames verdammt schnell, eben weil die cpu so schnell ist!
Sobald gpu1 mit ihren frame fertig ist, also bei Zeitpunkt 70ms will sie einen neuen von der cpu haben, welchen sie auch sofort bekommt, also bei Zeitpunkt 70ms, dazu weitere 60ms = 130ms. Gpu2 das selbe, nur 10ms später, also bei Zeitpunkt 140ms.
Dh, die ersten beiden frames SAHEN wir bei 70ms und 80ms, die nächsten beiden bei 130ms und 140ms, also 60ms nach den ersten beiden frames, und 50ms beim ersten Übergang vom neuen "2er Set".

Unterschied frame 1 zu frame 2 -> 10ms.
Unterschied frame 2 zu frame 3 -> 50ms.
.
.
.
usw usf.

-> die berühmte 10-50 Kadenz, welche real zwar ~30fps sind, aber wie 20fps aussieht.

Wenn man jetzt einfach frame 2, welcher zu einem SEHR FRÜHEN Zeitpunkt berechnet wurde, nämlich bei Zeitpunkt 10ms (!!), einfach nach hinten schiebt, dann bekommt man ja immer noch die INHALT von Zeitpunkt 10ms und nicht den aus 30ms, denn die cpu hat die ganze Geometrie, Texturen usw ja nicht aus der Zukunft (30ms sind ja noch Zukunft zu der Zeit), sondern eben aus 10ms.

Fazit: verschobene frames zeigen NICHT den gleichen INHALT wie zum richtigen Zeitpunkt berechnete frames, also wie bei einer single Karte.

Man muß also irgendwie der CPU sagen, sie soll, abhängig von der GPU Geschwindigkeit, warten.

Das erklärt auch, warum die Kadenzen sich ständig ändern, auch innerhalb der selben Anwendung, eben immer abhängig von der cpu Last. Je geringer die Last für die Cpu, also je stärker die cpu im Vergleich zur GPU ist, desto schlimmer wird das Problem.

Grestorn
2008-02-19, 08:39:49
Ich war ja länger gebanned, aber Saaya@ XS.org hat mich auf was gebracht. Er meinte nämlich, daß die reine Verschiebung des frames nix bringen würde, also so wie es der Ludi limiter macht.
Denn der INHALT des verschobenen Bildes ist ja immer noch der aus der zu frühen Zeit!! Also wenn die Kadenz zb 10-50 ist, und man einfach 20ms bei den 10ms wartet, dann hat man zwar 30-30, aber der INHALT des Bildes vom ersten 30er wäre immer noch der vom 10er!!
Dh man würde das erste Bild, bzw die Information des ersten Bildes, zu einem
falschen Zeitpunkt sehen.

Deswegen muss die Verzögerung durch den Treiber geschehen und zwar beim D3D "Release()" call der sich auf die erste der beiden SLI Karten bezieht. Dann würde auch die CPU entsprechend korrekt verzögert und das Bild wäre im Zeitstrang korrekt positioniert, sowohl vom Inhalt als auch vom Zeitpunkt der Darstellung.

P.S.: Welcome back!

Fatality
2008-02-19, 08:46:11
Hast du NV mal darauf schriftlich hingewiesen?

tombman
2008-02-19, 08:58:43
Hast du NV mal darauf schriftlich hingewiesen?
Wozu? Die wissen das eh...

tombman
2008-02-19, 09:00:39
Deswegen muss die Verzögerung durch den Treiber geschehen und zwar beim D3D "Release()" call der sich auf die erste der beiden SLI Karten bezieht.

Hmm, kann man sich da nicht mit ner gemoddeten d3d.dll, oder sowas in der Art, reinhacken? ;D

Ich habe doch zb da dieses japanische tool, was jede d3d Anwendung ins Fenster zwingen kann (d3d windower) oder zb dieses tool welches den FOV ändern kann aus dem widescreengaming Forum.
Wie machen die das denn?

Daß es PERFEKT geht zeigt mir doch Half Life 2. Per console command kann man perfekt auf zb 30fps limitieren.

Fatality
2008-02-19, 09:06:51
ich meine jetzt grestorn,
evtl bekommst du eine antwort zu deinem vorschlag.

Grestorn
2008-02-19, 09:10:15
ich meine jetzt grestorn,
evtl bekommst du eine antwort zu deinem vorschlag.

Nein, habe ich nicht. Wenn nVidia überhaupt mal anfängt sich dieses Problems zu widmen, dann bin ich auch sicher, dass sie dieses Detail korrekt berücksichtigen. So dumm sind die ja auch nicht... :)

Allerdings muss das Problem noch intensiver in der Presse (On wie Offline) besprochen werden, damit der Druck wächst. Karten wie die GX2 spielen da auch eine wichtige Rolle, da sie SLI stärker im Markt positionieren.

Grestorn
2008-02-19, 09:13:45
Hmm, kann man sich da nicht mit ner gemoddeten d3d.dll, oder sowas in der Art, reinhacken? ;D

Kann man sicher.

Wenn Du meinst, ob ICH das kann... ja, sicher, wenn ich genügend Zeit hätte. Ich müsste mir aber erst eine Menge für mich komplett neues Wissen aneignen.

Andere haben da viel mehr Erfahrung, z.B. wie man einen Hook an der richtigen Stelle in D3D platziert.

Der Treiber tut sich dennoch mit alldem viel leichter als so etwas über ein externes Tool zu regeln, dass sich einhacken muss und dem immer wichtige Infos fehlen, die dem Treiber grundsätzlich bekannt sind.

tombman
2008-02-19, 09:45:37
Allerdings muss das Problem noch intensiver in der Presse (On wie Offline) besprochen werden, damit der Druck wächst. Karten wie die GX2 spielen da auch eine wichtige Rolle, da sie SLI stärker im Markt positionieren.
Am besten noch gleichzeitig zum GX2 launch -> DAS tut weh :cool:

2x GX2 @ quad sli- und dann in den Printmedien das Problem schön breittreten :devil:

PCGH_Raffael
2008-02-19, 09:59:26
Allerdings muss das Problem noch intensiver in der Presse (On wie Offline) besprochen werden, damit der Druck wächst. Karten wie die GX2 spielen da auch eine wichtige Rolle, da sie SLI stärker im Markt positionieren.

Also wir haben dazu einen Zweiseiter in der kommenden Ausgabe 04/2008.

MfG,
Raff

Mr. Lolman
2008-02-19, 10:00:55
2x GX2 @ quad sli- und dann in den Printmedien das Problem schön breittreten :devil:

Das wird sich niemand trauen.

tombman
2008-02-19, 10:18:35
Also wir haben dazu einen Zweiseiter in der kommenden Ausgabe 04/2008.

Bekomme ich eine Ehrenausgabe geschenkt? :)

Btw, werde ich dort erwähnt? :eek:

p.s.: auch wenn nicht, sowas in ner print Ausgabe ist auch so schon :massa:

Lotzi
2008-02-19, 11:29:21
willkommen zurück aus deinem Urlaub Tombman

Sonyfreak
2008-02-19, 11:43:30
Also wir haben dazu einen Zweiseiter in der kommenden Ausgabe 04/2008.Sehr feine Sache! Vielleicht kümmert sich dann Nvidia endlich um das Problem, und SLI wird auch für mich interessant. :)
Btw, werde ich dort erwähnt? :eek:Verdient hättest dus dir auf jeden Fall! :up:

mfg.

Sonyfreak

Gast
2008-02-19, 12:28:34
PCGH Exklusiv: Multi-GPU - wenn Mikroruckler zu Makrorucklern verkommen

http://www.pcgameshardware.de/aid,632763/News/PCGH_Exklusiv_Multi-GPU_-_wenn_Mikroruckler_zu_Makrorucklern_verkommen/

Mr. Lolman
2008-02-19, 13:57:13
Workaround: Fps-Limiter
Ein aktueller Lösungsansatz besteht darin, die Framerate künstlich zu drosseln. In diversen Foren findet sich ein Tool, das die Fps auf einen beliebigen Wert fixieren kann (Download). Es bestimmt, nach welcher Zeit ein Frame dem nächsten folgen darf. Sofern das Grafikkartenduo in der Lage ist, konstant 30 Fps zu liefern, ist die Wirkung unübersehbar: Die Mikroruckler sind verschwunden und Fraps misst kaum noch Abweichungen
.
Wenn Sie das Tool nutzen möchten, dann sollten Sie ein paar Dinge beachten. Erstens unterstützt es in der (von uns getesteten) Version 0.2 noch kein Direct3D 10, lediglich 8, 9 und OpenGL. Um eine Anwendung mit dem Programm zu starten, erstellen Sie zuerst eine Verknüpfung zum Limiter. Unter "Ziel" fügen Sie nun den Pfad der gewünschten Ausführungsdatei ein. Beim 3DMark 06 sieht das folgendermaßen aus:

"C:\fpslimiter\FPS_Limiter.exe" "D:\3DMark06\3DMark06.exe"

Vorgegeben ist eine 30-Fps-Barriere. Möchten Sie den Wert ändern, etwa auf 40 Fps, müssen Sie "/f:x" (ohne Anführungszeichen) zwischen die beiden Pfade schreiben. X steht dabei für die gewünschte Fps-Grenze (etwa 40). Mit den Tasten F10 und F11 lässt sich der Wert im Spiel aber ändern. Alles weitere steht in der beigelegten Readme-Datei.
(Raffael Vötter)

Damit wird zwar die Kadenz geglättet, aber der Frameinhalt bleibt der Gleiche. Siehe dazu auch das Post von Tombman: http://www.forum-3dcenter.de/vbulletin/showthread.php?p=6292139#post6292139

Raff
2008-02-19, 14:01:54
Ja, es wirkt aber schon deutlich besser als unlimitiert.

MfG,
Raff

Gouvernator
2008-02-19, 16:00:14
Wenn jetzt einer nicht gesagt hätte das Bild ist nicht mehr das was eigentlich sein müsste wäre ich nicht drauf gekommen...nie. Deshalb - egal. :)

Gast
2008-02-20, 21:50:15
Du musst nur mal den 3DMark05 anwerfen. Ganz evil. Makro- und Mikroruckler kombiniert.

MfG,
Raff

Werd ich testen. Hab bisher nur 3DMark03 und zum Spaß 2001 SE laufen lassen, da war nichts feststellbar... evtl. wegen der generell höheren Frameraten? (die dürften ja mit S3-Karten in 3DMark05 extrem niedriger sein als im 03er...) Oder ist es die übliche Abhängigkeit von der Anwendung?

Reduzieren VSync mit/ohne Triplebuffering die Problematik jetzt, verstärken sie sie oder ist der Einfluss eher gering?
Ist mir jetzt ehrlich gesagt nicht ganz klar... habe bislang den Eindruck als ließe sich keine allgemeingültige Aussage treffen (was ja auch ne Aussage wäre, zugegeben ^^).

Gast
2008-02-20, 22:29:11
Ich war ja länger gebanned, aber Saaya@ XS.org hat mich auf was gebracht. Er meinte nämlich, daß die reine Verschiebung des frames nix bringen würde, also so wie es der Ludi limiter macht.
Denn der INHALT des verschobenen Bildes ist ja immer noch der aus der zu frühen Zeit!! Also wenn die Kadenz zb 10-50 ist, und man einfach 20ms bei den 10ms wartet, dann hat man zwar 30-30, aber der INHALT des Bildes vom ersten 30er wäre immer noch der vom 10er!!
Dh man würde das erste Bild, bzw die Information des ersten Bildes, zu einem
falschen Zeitpunkt sehen.
Entweder BeginScene() oder EndScene() müssten ja eigentlich blocken, wenn das Prerenderlimit erreicht ist (sonst wäre einfach die Framerate höher). Ich weiß nicht wie Ludi es realisiert hat, aber ich kann mir verstellen, dass seine Variante den Block lange genug aufrecht erhält, um die Grafikengine genügend auszubremsen, damit das nächste Bild passend berechnet wird.

Gast
2008-02-23, 05:05:07
Also wir haben dazu einen Zweiseiter in der kommenden Ausgabe 04/2008.

MfG,
Raff

Wird der tombaman wenigstens dort mal erwähnt????
Denke schon das ihm das schuldig seid..............

Gast
2008-02-23, 05:05:36
Wird der tombaman wenigstens dort mal erwähnt????
Denke schon das ihm das schuldig seid..............

tombman natürlich....

Gast
2008-02-23, 11:58:22
Soweit ich gelesen habe, versucht Nvida das Problem von der Entstehungseite her zu beseitigen. An eine zwischen Lösung, wie z.b. der FPS_limiter wird nicht gearbeitet. Der die Ursache ja nicht beseitigt, sondern nur das Ergebniss verschlimmbessert wird.

Ergo, bedeutet das eine Überarbeitung der Datenübergabe. Die hohe Latenz kommt immer dann zu stande, wenn Informationen vom vorherigen Bild, für die gegenwärtige Berechung benötigt wird. Dabei ist die erste Graka immer schneller, da sie die daten noch im "Speicher" hat, wärend die zweite diese erst noch erhalten muß. Die betrifft vor allem den Vertex-shader. Daher ist das Problem bei Splittscreen rendering nicht so zu beobachten.

Ich denke, das besitzer der 7er Reihe wohl keine Lösung seitens Nvidia zu erwarten ist. Die letzten Treiber releases kammen alle nur noch für 8er und 9er raus.

Gast
2008-02-23, 12:14:00
Was mich interessieren würde, welche System die anfälligsten für Mikroruckler sind.
Denn bei vielen tretten keine Probleme bzw. nicht so große Probleme auf. Bei anderen wieder sehr gravierende. Wenn das rucklen zugleich noch durch die CPU-Last verursacht wird, wäre es sicher interessant, ob es da unterschiede zw. Intel und AMD gibt. Und zwischen highend und mainstream-CPU.

z.b habe ich ein eher langsames System : AMD64 X2 mit 2,7GHz und SLI 7900gt512. Sprich CPU bremst Graka aus.

Gast
2008-02-23, 14:45:50
quark, deine grakas bremsen die cpu aus, jedenfalls in der für mich normalen auflösung von 1680*1050 mit 4xaa und 16xaf

Gast
2008-02-23, 18:58:59
Es ist eigentlich ein Skandal, daß ATI und Nvidia dazu noch nicht gesagt haben, aber angeblich von dem Problem wissen (nach Computerbase, die es nicht mal für nötig hielten, Tombman zu erwähnen).Wo das??

Gast
2008-02-24, 16:19:14
quark, deine grakas bremsen die cpu aus, jedenfalls in der für mich normalen auflösung von 1680*1050 mit 4xaa und 16xaf


Äh...hab nur SLI7900gt und kann von solchen Auflösungen nur träumen. Bzw. bekomme in diesem bereich erst garkeine flüssigne Frames.

Standard ist: 1280x1024 mit 4xaf und 4xaa, wenn aa dann ohne HDR. Zumindest bei neueren Spielen:NFS PS, Crysis, COD4 etc.

kahlchen
2008-03-06, 14:34:54
NVIDIA bestätigt Mikroruckler :)

http://www.hardtecs4u.com/news/1472_cebit_nvidia_bestaetigt_mikroruckler_und_kuendigt_loesung_an

//EDIT
hab gerade gesehen, wurde ja schon in anderem thread gepostet :redface:
//

Grestorn
2008-03-06, 14:36:47
NVIDIA bestätigt Mikroruckler :)

http://www.hardtecs4u.com/news/1472_cebit_nvidia_bestaetigt_mikroruckler_und_kuendigt_loesung_an


...alles wird gut! :)

Danke für den Link!

Raff
2008-03-06, 14:50:18
Die Bestätigung (http://www.pcgameshardware.de/aid,633537/News/Multi-GPU_Mikroruckler_Erste_Statements_von_AMD_und_Nvidia/) ist alles andere als neu (http://www.pcgameshardware.de/aid,634496/Praxis/Mikroruckler_Untersuchungen_mit_aktueller_Forceware_und_9600-GT-SLI/). Es ist nur eine weitere. ;)

MfG,
Raff

Gast
2008-03-06, 15:42:33
...alles wird gut! :)

Danke für den Link!


Na Klaarrr

Zitat:"Da uns Nvidia aber freundlich darauf hinwies, dass der neue Forceware-Treiber schon Verbesserungen bezüglich des Mikroruckelns aufweisen soll, überprüften wir das Problem erneut mit einem SLI-Duo - diesmal bestehend aus Geforce 9600 GT-Karten."


Fazit-->"Die Geforce 9600 GT ist trotz des neuen Treibers auch vom Mikroruckeln befallen, und das deutlich."

http://www.pcgameshardware.de/aid,634496/Test/Benchmark/Mikroruckler_Untersuchungen_mit_aktueller_Forceware_und_9600-GT-SLI/

Coda
2008-03-06, 16:06:28
Jetzt wartet doch erstmal ab. Ich bin aber auch sehr skeptisch.

4 Vitamins
2008-03-06, 16:14:24
Wenn ati sagt es muss im kernel von xp und vista verbessert werden, wie kann es dann nvidia mit nem treiber beseitigem??

gruss

2B-Maverick
2008-03-06, 16:16:50
Wenn ati sagt es muss im kernel von xp und vista verbessert werden, wie kann es dann nvidia mit nem treiber beseitigem??

gruss

Weil ATI es sich eventuell (?!) zu einfach macht?! :confused:

Grestorn
2008-03-06, 16:24:21
Wenn ati sagt es muss im kernel von xp und vista verbessert werden, wie kann es dann nvidia mit nem treiber beseitigem??

gruss

Es ist immer noch der Treiber, der weiß wann eine Karte mit dem Rendern fertig ist, und das dem Rest des Systems mitteilt. Deswegen habe ich die Aussage von ATI auch nicht nachvollziehen können. Erschien mir eher wie eine Ausrede.

Blaire
2008-03-06, 16:25:42
Es ist immer noch der Treiber, der weiß wann eine Karte mit dem Rendern fertig ist, und das dem Rest des Systems mitteilt. Deswegen habe ich die Aussage von ATI auch nicht nachvollziehen können. Erschien mir eher wie eine Ausrede.

Gut zu hören das es bald (hoffentlich) eine Lösung geben wird. :)

Gast
2008-03-06, 16:25:59
Wenn ati sagt es muss im kernel von xp und vista verbessert werden, wie kann es dann nvidia mit nem treiber beseitigem??

gruss

ati sagt eine Lösung im Kernel wäre das beste weil das Problem auch da liegt
eine "Lösung" im treiber wäre höchstens ein Workaround - sprich pfusch.

Gast
2008-03-06, 17:34:12
ati sagt eine Lösung im Kernel wäre das beste weil das Problem auch da liegt
eine "Lösung" im treiber wäre höchstens ein Workaround - sprich pfusch.
Besser als gar nichts. Wenn es an das Ergebnis des selbst programmierten framelimiters ran kommt, ist das schon ein Riesenfortschritt.
Für alles andere müsste wohl MS bei Vista und XP Handanlegen.
Ob das passiert ist fraglich, mein Leben würde ich darauf nicht verwetten wollen, es sei denn, ich wäre lebensmüde.

Gast
2008-03-08, 10:01:27
So...ich für meinen Teil hab mir meine Meinung gebildet. Nachdem ich zuerst der Ansicht war, dass Mikroruckler nicht zwangsläufig auf allen Systemen vorkommt, behaupte ich, das alle SLI/CF mikroruckler aufweisen und das auch sichtbar und selbst bei hohen FPS.
Habe jetzt den vergleich von 4 SLI/CF Lösungen auf einer Lanparty gemacht.

Und ich habe bei allen Mikroruckler gesehen. Vielleicht hab ich aber auch Wahrnehmungstörungen, da 3 von ihnen bombenfest meinten ihr Bild sei flüssig, trotz offensichtlicher Mikroruckler.

SLI 8600gt, SLI 7900gt, CFx2900XT, 7950gx2

Gespielt wurde Flatout2: was auf allen Systemen mit höchester Auflösung absolut "Flüssig" lief. Und bei Nvidia im Single-GPU Modus läuft. Bei ATI war der Modus leider nicht rauszubekommen. Speziell Ruckler der Streckenumgebung, das Fahrzeug selbst war flüssig, aber die umgebung zum Rand hin zuckte bei allen an einem vorbei.

Für mich ist SLI/CF nach der Erkenntnis gestorben.

Gast
2008-03-08, 10:05:49
Nvidia behauptet, das angebliche Verbesserungen zur bekämpfung von Mikrorucklern im Treiber 174.16 für die 9600er eingebaut worden sind. Verbesserungen wurden jedoch nicht festgestellt. Quelle: Tomshardware.com.

Also auch die 9er Reihe von MR betroffen.

Luke007
2008-03-09, 15:15:12
Habe mir nun Testweise ein SLI System mit zwei 8800GT 512MB Karten aufgebaut. Unter Crysis sind die Mikroruckler zwischen 25 bis 40 FPS so bemerkbar (auch mit Fraps gemessen), dass es schon garkeinen Spass macht. Da läuft es viel besser mit einer Single Karte.
Absolutes "No Go"!
Ich teste weiter.

EDIT:
Ahja falls es noch jemanden interessiert, ich verwende den 174.16 Treiber mit passender INF.

Gast
2008-03-09, 16:37:27
Teste es mal mit dem FPS Limiter wie schön es sich dann spielt ;)

Gast
2008-03-11, 15:30:09
Gibts vielleicht ein Video damit ich mal sehen kann wie Mikroruckler aussehen? Die meisten haben kein SLI und ich weiß nicht so recht wie es aussieht bzw. ob es mich stören würde.

Spasstiger
2008-03-11, 15:36:22
Gibts vielleicht ein Video damit ich mal sehen kann wie Mikroruckler aussehen? Die meisten haben kein SLI und ich weiß nicht so recht wie es aussieht bzw. ob es mich stören würde.
Wenn du bei pcgameshardware.de angemeldet bist:
http://www.pcgameshardware.de/aid,631607/Praxis/Videobeweis_Mikroruckler_zerstoeren_den_leistungssteigernden_Effekt_von_Multi-GPU-Loesungen/

Du Videos sind auch auf der aktuellen Heft-DVD.

Gast
2008-03-11, 15:47:12
Danke, dafür brauch ich nicht angemeldet sein, das sieht man auch schon in schlechter Qualität im Flash-Fenster. Bäh!

Und das tritt auch auf Multi-GPU-Karten wie der 3870 X2 auf? Na dann bin ich gespannt wie lange es dauert bis es eine echte Lösung gibt, bzw. wie lange es dauert bis NVidia und AMD bei Single-CPU Karten die Performance nochmal erhöhen. Denn in dem Fall ist die 8800GTS G92 die schnellste Karte für einen vernünftigen Spiele-PC da die GTX und Ultra überteuert sind und die Multi-GPUs bei solchen Nebeneffekten keine Alternative darstellen.

Mich wundert nur, dass die Mikroruckler-Debatte erst jetzt angelaufen ist wo es SLI und die 8800 Serie schon so lange gibt. Ist das denn bisher die letzten Jahre niemandem aufgefallen?

Spasstiger
2008-03-11, 19:59:30
Mich wundert nur, dass die Mikroruckler-Debatte erst jetzt angelaufen ist wo es SLI und die 8800 Serie schon so lange gibt. Ist das denn bisher die letzten Jahre niemandem aufgefallen?
Vermutlich ist es den Leuten schon aufgefallen, aber da die Spiele meist immer noch besser als mit einer Karte liefen und da die fps-Anzeige auch besänftigte, hat man es wohl nicht genauer hinterfragt.

AYAlf
2008-03-24, 10:48:25
hab nix angekreuzt ...

kenne micro und large ;D ruckler nur von nvidia ... und da hat es nicht nur mit vsync zu tun. :tongue: