Microruckler nur unter 30FPS bemerkbar?

[Mr.Mushroom]

Wie es aussieht sind auch bei 50FPS Microruckler, oder sind einfach zu viele Nvidia Leutz da;
Mhm, merkwürdig...kann einem echt verwirren die ganze Sache!

Greetz.Mr.Mushroom

 

[Realsmasher]

wieso nvidia leute ? das ganze ist bei sli genauso

 

[Rush|]

Jetzt fangen wieder diese Aufsätze an. Jetzt gibt es einen Ansatz auf eine Lösung jetzt kommt schon wieder jemand mit Ghosting. Einfach mal den Mund zu und bald werden wir es sehen. Meine ....

 

[ScoutX]

@ Realsmasher: So wie ich dich verstehe, bedeutet dieses folgendes: alle Frames einer Sekunde werden mit der 3,3 Meter Änderung berechnet. Es ist unerheblich, ob die Frames in homogenen oder inhomogenen Zeitabständen kommen. Die Berechnung erfolgt z.B. durch Änderung der Ortskoordinaten der Polygonmodelle in Matrizenform über eine im voraus (!) kalkulierte Zeit bzw. Geschwindigkeit (CPU-Clock bzw. interner Timer). Der Programmierer bzw. die Gameengine gibt die Änderung der Ortskoordinaten an, die in einem festgelegten Zeitintervall vollendet sein sollte, sofern nicht ein Overwrite-Befehl kommt.
Ich dachte immer, dass die aktuellen Grafikkarten oder die neueren Gameengine so "intelligent" wären, Ortsveränderungen komform mit der vergangenen Echtzeit zu berechnen, d.h. wenn 66 ms bzw. 100 CPU-Clockzyklen vorbei sind adaptiv die Veränderung der Ortskoordinaten anzupassen.
Wenn man von deinem Beispiel 3,3 Meter pro Frame ausgeht, dann ist dieses also kein Mittelwert aller Frames , sondern der tatsächliche Wert?!
Wenn die Grafikkarte oder auch die Gameengine die Geschwindigkeit in gleichmäßigen Frameänderungen für 2 GPUs vorkalkuliert (wie?), dann sehe ich für die Mikroruckler kaum einen Workaround.
Mir erscheint das Prinzip der Vorkalkulierung suboptimal.
Ich wußte nicht, dass die heutigen Gameengines noch so weit entfernt vom Echtzeitrendering sind.

 

[Realsmasher]

was du beschreibst geht leider nicht.

Der ablauf ist in etwa so wenn man es vereinfacht darstellt nur für die grafische ausgabe :

- erst wird der input aufgenommen
- danach kommen bewegungen, d.h. eingabe wird umgesetzt, ki, physik
- danach prüfung auf kollisionen
- JETZT wird ein frame erzeugt
- danach beginnt es von neuem

Nehmen wir nun an wir haben eine cpu die 50fps im optimalfall schaffen kann, dann braucht sie für den berechnungszyklus(die punkte 1-3) genau 20ms.

du kannst den rendering vorgang aber erst starten wenn diese berechnung vollständig abgelaufen ist.

Würdest du früher starten hättest du z.b. probleme damit das Objekte sich ineinander verschieben, weil noch keine Kollision geprüft wurde usw.

Das ganze ist ein strikter Ablauf und MUSS komplett ausgeführt werden und zu großen Teilen sequentiell(u.a. ein grund dafür warum Mehrkernprozessoren auch heute bei vielen Spielen noch nicht so viel bringen).



Natürlich erfolgt die bewegung IN DER CPU nach abgelaufener zeit, also z.b. 1 meter pro 10ms, aber das hat nichts mit der ausgabe durch die grafikkarte zu tun.


wenn z.b. durch mikroruckler frames im abstand von 10-50-10-50 ausgegeben werden, dann hat die cpu trotzdem 30ms pro frame berechnet und die bewegung innerhalb der frames ist völlig homogen.


Ausnahmen dazu gibt es allerdings bei manchen Spielen wie hdr, welche mit sinkenden framerates langsamer ablaufen, aber darauf jetzt auch noch einzugehen sprengt wohl den rahmen.


Fazit ist jedenfalls : die von der cpu and die gpu(s) übergebenen Informationen sind immer gleichverteilt.
Es läuft nicht so ab, das eine Grafikkarte Infos von der CPU anfordert, von exakt dem Zeitpunkt wo sie ihren Frame beginnen will zu rendern.



achja : das ganze was ich hier geschrieben hab basiert auf meinen eigenen Erfahrungen mit der 3D Programmierung !
Es ist durchaus möglich das einige Gameengines das völlig anders handhaben, aber ich halte es aus algorithmischer Sicht für völlig ausgeschlossen das die Grafikkarte die Geschwindigkeit "bestimmt". Das würde an viel zu vielen Stellen zu Inkonsistenz und/oder Verzögerung führen.

 

[lizardking78]

Ladet Euch den Frametimelimiter runter damit dürfte es soweit spielbar sein!


ohne fpslimiter, also mit Mikroruckler:
Standardabweichung: 8,92 ms über 100frames.

mit fpslimiter, ohne sichtbare Mikroruckler:
Standardabweichung: 0.672 ms über 100frames.

Alle test mit 3dmark06 auf Standardeinstellung (default) und canyonfly.

Den Framelimiter gibt es hier zum Download: http://rapidshare.com/files/85231450/fpslimiter_0_2.rar

Mein Tagebuch: http://extreme.pcgameshardware.de/showthread.php?t=9723

 

[Realsmasher]

danke für den download-link, ich dachte shon ich würde das ding nie finden nachdem es von ludis website verschwunden ist.

ich seh auch grad das er extra dlls erstellt hat für die methoden.

Muss mich da mal reinarbeiten, eventuell kann man ja doch noch was anpassen bezüglich variabler frames.

dx10 hingegen wird es wohl leider nnie in den limiter schaffen

 

[lizardking78]

wir sind dran eine Sammelklage zu machen...nee also ich möchte einen Thread aufmachen in dem sich alle SLI-CF User treffen und ein Statement an die Grakahersteller abgeben und dies dann an die Hersteller weiterleiten...damit da mal ein wenig was passiert...nun wenn ein Ludi schon lösungen so schnell findet dann erwarte ich das längst von den Herstellern!

 

[Mr.Mushroom]

Also, jetzt ich hab jetzt nochmal alles durchgelesen und bin auf das gekommen:

Fazit...?:

1. Unter 50FPS treten noch gelegentlich Microruckler auf;
2. Es gibt ein Tool Framelimiter, diese gleich die Abstände aus und verhindert somit diese Microruckler.

Frage:

Kann man dieses Tool immer mitlaufen haben oder wie funzt das?
Ist es schon Bug frei und kann man sagen, wenn man dieses Tool mitlaufen hat, dann ist das Problem mit den Microrucklern behoben bzw. stark gelindert?

Mhm, man kriegt ja richtig Angst und Abneigungen vor SLI\FG\X2 wenn man das ganze liest;

Ich tendiere immer mehr zur Fast-Ultra
http://web.hoh.de/hoh/(S(askuwa45qgm4cb45wr3njf45))/default.aspx?TY=item&ST=1&IT=41015&CT=4499
...obwohl die X2 ein extrem geiles Gesamtperformancerating hinlegt...vor allem um die 1920x1200
https://www.computerbase.de/artikel...test.756/seite-24#abschnitt_performancerating
Sie wird auch von CB bei den empfohlenen Zusammenstellung ohne Alternativen empfohlen.
https://www.computerbase.de/forum/t...g-pc-spiele-pc-selbst-zusammenstellen.215394/

Greetz.Mr.Mushroom

 

[Rush|]

Mr.Mushroom man das was du da machst ist lächerlich. Du willst nur einmal hören das die HD 3870 X2 gut ist und ohne Probleme läuft, damit es dir und deiner Ehre gut geht. Man kann sich da nichts gut reden. Es gibt Fakten.

Die HD 3870 X2 ist die beste Karte.
Es gibt aber Mikroucker, DOCH es kann leicht behoben werden.

Jetzt musst du es selber wissen. Holst du dir eine alte Ultra mit guter Leistung oder eine moderne HD 3870 X2 mit besserer Leistung für weniger Geld. Man man.

 

[Child]

Mushroom, ich hab die X2 jetzt seit Ende letzter Woche und hab bis jetzt keine Probleme mit Mikrorucklern. Wenn du halbwegs experimentierfreudig bist - kauf dir das Ding. Die Performance is super. Wenn sie dir nich zusagt dann kannst sie ja wieder verkaufen und dir ne GTX holen - verlierst eben etwas Geld, aber soviel auch wieder ned.

 

[lizardking78]

ich habe 2xGTS im SLI laufen und noch habe ich auch keine Microruckler gehabt...außer Testweise herausgefordert um den Framelimiter zu testen...den brauchte ich aber noch...nicht!

 

[Rush|]

Mushroom, ich hab die X2 jetzt seit Ende letzter Woche und hab bis jetzt keine Probleme mit Mikrorucklern. Wenn du halbwegs experimentierfreudig bist - kauf dir das Ding. Die Performance is super. Wenn sie dir nich zusagt dann kannst sie ja wieder verkaufen und dir ne GTX holen - verlierst eben etwas Geld, aber soviel auch wieder ned.

Ich würde sie nicht wieder verkaufen wie du ihm geraten hast. Ich denke das es so ein Framelimiter auch im neuen Treiber geben wird!(hoffentlich)

 

[Child]

Ich rate ihm ja auch nich sie in jedem Fall wieder zu verkaufen Wollte nur die Möglichkeit aufzeigen ... Naja aber im Cat-8.2 wirds da wohl keinen Fix dazu geben.

 

[DJFireDrum]

Eigentlich ne blöde Frage... ^^ weil alles unter 30 FPS ist eh ruckelig, und da machen sich die Mikroruckler eh nicht so bemerkbar, finde ich...

 

[ScoutX]

Man hätte die Frage besser umstellen sollen: (Mikro)Ruckler auch bei Framewerten über 30 FPS bei MultiGPU Systemen wahrnehmbar? Aber selbst das trifft es nicht ganz. Denn was ist ein Microruckler? Gehört zu den Unwörtern des Jahres.

Ergo:
Erzeugt die asynchrone Frameberechnung bei MultiGPU-Systemen (AFR-Modus) auch jenseits von 30 FPS (Minimalangabe) eine für den Menschen wahrnehmbare Bildstörung in Videospielen?

Für die Doktorarbeit müsste man die in Klammern gesetzten Begriffe aus dem Titel streichen und in der Einleitung bringen.
Die Umfrageergebnisse finde ich bis jetzt sehr interessant: Ob da nicht TFT, Overdrive und Co. der Grafikkarte gute Dienste leisten?

 

[Realsmasher]

Ob da nicht TFT, Overdrive und Co. der Grafikkarte gute Dienste leisten?

das ist immer noch ein Punkt den ich sehr interessant finde und auf den praktisch nie eingegangen wird.

Selbst moderne, vernünftige Monitore zeigen Bilder ja häufig erst 20-30ms später an. Speziell bei guten MVAs ist das eher die Regel als die Ausnahme.

Dürfte in dem Fall nicht die zeitliche Grafikausgabe ohnehin geglättet werden ?

Oder zeigen die Monitor auch wirklich nur solange ein bild an, wie der abstand zum vorigen beim erhalt war ?


Die Frametimes zum nachweis von mikrorucklern sind eine sache, aber die sagen ja eben nur wann die bilder von der graka losgeschickt werden und nicht wann und wie lange sie wirklich zu sehen sind....

 

[ScoutX]

Wie ich schon in meinem ersten Post andeutete, empfinde ich Ruckeln auf einem CRT mit 100+ Hz im Framegrenzbereich deutlich stärker als es auf einem TFT überhaupt möglich ist.
Wenn man von 30 FPs ausgeht und diese Frames auch vollständig angezeigt werden sollen, so müßte jede 33 ms ein neuer Frame an den PC Monitor geschickt werden. Bei 50 FPS und mehr skaliert jeder halbwegs normale TFT mit seiner Bilderneuerungsrate nicht mehr mit den angebotenen Frames.
Daraus folgt für mich, dass bei einem TFT eine Framebegrenzung vorhanden sein muss und nicht jeder Frame aus dem Puffer genommen werden kann. Im Umkehrschluß ziehe ich daraus aber auch die Konsequenz, dass gerade in Grenzfällen der Puffer Frameeinbrüche kaschiert und durch die "Standbildfunktion"/ kein erzwungener Neuaufbau des Bildes Frameeinbrüche kaum zu sehen sind. Bei einem 100 Hz CRT hingegen ist jedes Frame entscheidend.

Aber wie Realsmasher schon sagte: Um der Sache auf den Grund zu gehen, müsste man endgültig in Erfahrung bringen, wie und ob TFTs zwischengespeicherte Frames gleichmäßig über die Zeit ausgeben und wann ein Frame fallengelassen wird.