News Neue Framelatenz-Diagramme auf ComputerBase

[MadManniMan]

Danke Relaxo,

jetzt liest sich Deine Einschätzung schon weniger aufgeregt.

Mir ging in diesem Thread auf den Keks, dass die Framelatenz-Problematik breit als Nvidia-Lobhudelei uminterpretiert wurde und meines Erachtens ging Dein selektives Zitat zu sehr an der Erkenntnis vorbei.

Jetzt stimme ich Dir auch vollumfänglich zu: das Thema wurde bisher nicht annährend ausreichend betrachtet! Gerade auch von der PCGH hätte ich da weitaus mehr erwartet. Schön, dass die CB hier vorangeht!

 

[Kowa]

was mich interessieren würde:
was ist der Grund dafür, daß ATI solche Ruckler produziert?
EDIT: ist es vielleicht ein Fehler im Treiber?

Ich vermute, dass da Texturen nachgeladen werden müssen.

Falls das stimmt, sollte richtig schneller Speicher, statt DDR3-1600 die Diagramme etwas verbessern.
Großer Speicher bringt evtl. auch etwas, allerdings nur, wenn das Spiel nicht dauernd neue Texturen liefert.

Bei AMD gab es ja auch mal was mit Textur-Kompression, weiß nicht, ob die das noch verwenden. Vlt löst das auch so eine Kunstpause aus.

 

[MadManniMan]

Ich vermute, dass da Texturen nachgeladen werden müssen.

Falls das stimmt, sollte richtig schneller Speicher, statt DDR3-1600 die Diagramme etwas verbessern.
Großer Speicher bringt evtl. auch etwas, allerdings nur, wenn das Spiel nicht dauernd neue Texturen liefert.

Bei AMD gab es ja auch mal was mit Textur-Kompression, weiß nicht, ob die das noch verwenden. Vlt löst das auch so eine Kunstpause aus.

Geht es gerade um eines der Diagramme, bei denen die Ruckler regelmäßig in Abständen unter einer Sekunde auftreten?

 

[Krautmaster]

gut, ich denke ein gesonderter Test mit diversen Settings Plattformen wäre im Interesse vieler hier.

Wenn im GPU Test selbst dann mit "default" Treiber Werten geprüft wird ist das absolut iO. Ich habs gern ohne Treiberexperimente. Angeischts dieser Umstände/Kompexität verstehe ich solangsam auch NVs Unternehmen dahingehend die optimalen Settings übers Netz zu laden und die Endanwender bezüglich Treiber Settings zu entlasten.

 

[Kowa]

Ich verstehe wirklich nicht, was diese Diskussion über "Fanboys" soll. Lasst doch jeden hier seine Meinung schreiben und fertig.

Wohl jeder hier im Forum hat seine Hardware mit Bedacht und nach langer Abwägung gewählt. Klar dass man bei einem negativen Artikel ein wenig pikiert ist, bedeutet ein Fehler des Produktes schließlich auch dass man selber einen Fehler gemacht hat, was wiederum Inkompetenz nahelegt.

Der Artikel vom Wochenende war recht interessant, zumindest für mich, weil ich von diesen starken Schwankungen bisher nie etwas offizielles gelesen habe, aber vor Jahren mit meiner ATI 850-XT bereits ähnliche Probleme hatte, die es mit einer nVidia-Karte nicht gab.

Dies, die Darstellung von Rauch und Oberflächen und das opulente CCC (welches .Net benötigte) haben mich zum Wechsel veranlaßt. Wenn es solche Kritiken nicht gäbe, würden es die Hersteller wohl nie mitbekommen, wo sie nachbessern sollten. Es liegt in der Natur der Sache, dass man als Hersteller betriebsblind ist. Das gilt auch für nVidia, als die Strom durchgeleitet haben wie ein Shunt.

Der heutige Artikel ist auch für mein Empfinden als nVidia-Owner etwas mißformuliert. Es wirkt, als wolle man nochmal den Finger in die Wunde legen, obwohl AMD bereits Besserung angekündigt hat. Dieser Artikel hätte entweder VOR dem Test als Ankündigung platziert werden müssen oder in Verbindung, dass AMD einen neuen Catalyst herausbringt.
So taucht er einfach 2 Tage später auf und wirkt wie AMD-Bashing. Kein Wunder dass sich die Fanboys angegriffen fühlen.

Generell ist dieses Fanboytum gut, wenn es dem unterlegenen Produzenten über eine schwierige Phase hilft. Bei Grafikkarten haben wir Glück, dass es trotz nur noch 2 Marktteilnehmern eine gute Konkurrenzsituation gibt. Bei CPUs ist der Zug abgefahren und wird uns noch viele € und einiges an Fortschritt kosten.

 

[vander]

Wie werden den diese "neuen" Diagramme erstellt? Ich vermute das es dafür kein Tool gibt das die Diagramme für ein 3D Programm automatisch generiert, also ist es wohl eher eine Log von einem Tool wie Fraps im Zusammenhang mit einer "manuellen" Auswertung über eine Excel Tabelle oder ein selbst geschriebenes Programm?

 

[Kowa]

Wie soll eine Ursachenforschung aussehen wenn die Ursache im Quellcode vom Treiber steckt, was AMD ja schon selber bestätigt hat?

Das Problem tritt halt bei AMD Karten auf, also ist es negativ für AMD. Punkt.

Die Welt ist aber oft nicht so einfach, wie wir sie gerne hätten. Punkt.

Die Ursache liegt sicherlich an ganz anderer Stelle und im Treiber wird keine Lösung sondern nur ein Workaround implementiert. Das Witcher-Diagramm legt die Vermutung nahe, dass nVidia gleich zu Beginn viele Texturen lädt und AMD erst bei Bedarf seinen Speicher füllt. Daher bezieht sich AMDs Aussage "Speichermanagement" womöglich nicht nur auf die Grafikkarte.
Das Diagramm von THG stärkt die Vermutung, dass AMD eben auf AMD-Plattformen entwickelt und womöglich bei Datentransfers auf diesen Plattformen problemlos bedient wird.

Mein ganz persönlicher Eindruck, als ich vor 5 Jahren vom Athlon-XP auf C2D wechselte, war ein ungleichmäßiges ruckeliges Arbeiten. Benchmarks, Transcoding, Frameraten waren ohne jede Frage auf dem C2D besser. Dennoch hatte ich stets das Gefühl, dass jede Interaktion erst mit Verzögerung in Gang kommt. Ich habe das darauf geschoben, dass intel immer erst große Datenblöcke cached und dann richtig loslegt, während AMD durch die überlegene Hyperchanneltechnik schneller an die Daten kommt, diese aber im Core nicht schnel genug verwursten kann. Ob diese Anschauung stimmt, habe ich nie weiter untersucht.

Früher gab es die BIOS-Option "PCI-Latency Timer". Hier konnte die Maximale Taktzahl eingestellt werden, die ein Gerät den Bus blockiert. War der Wert hoch, hatte man gute Übertragungsraten bei der HDD aber Aussetzer bei der TV-Karte. War der Wert niedrig, konnte die TV-Karte gleichmäßig ihre Daten an die Grafik weiterreichen, aber HDD- und andere DMA-Transfers wurden eben in kleine Scheibchen zerhackt und ausgebremst.
Beide Einstellungen waren nicht falsch und hatten ihre Berechtigung.

Will damit sagen, der Treiber von AMD ist nicht zwangsweise fehlerhaft, nur weil er sich nicht perfekt an jedes Biotop anpaßt. Trotzdem hoffe ich, dass die Medienaufmerksamkeit dazu beiträgt, das Problem schneller zu fixen.

 

[Teiby]

Wenn man sich hier die Framelatenz-Diagramme anschaut sieht man, dass Nvidia bei Battlefield 3 mehr Sprünge hat als AMD.

https://www.computerbase.de/artikel/grafikkarten/17-grafikkarten-test.2023/seite-7

Das liegt am RAM und der hohen Auflösung (behaupte ich mal). Ich hatte schon einen 2560x1440 Bildschirm und die HD7970. Der RAM war immer etwas über 2GB belegt. Die Geforce GTX 680 hat nur 2GB und die HD7970 hat 3GB. Bei kleinerer Auflösung sind die Ausreißer von beiden Grafikkarten wahrscheinlich gleich.

 

[.fF]

So taucht er einfach 2 Tage später auf und wirkt wie AMD-Bashing. Kein Wunder dass sich die Fanboys angegriffen fühlen.

Die meisten Leute fühlen sich hier nicht als Fanboy mich angegriffen. Sie fühlen sich schlecht informiert, gerade weil die Thematik im Test am Wochenende vollständiger wiedergegeben wurde. Z.B. mit Hinweis auf den 13.2er Beta-Treiber und auf die Zusage seitens AMD weitere Verbesserungen einzubauen, wie du auch selbst erwähnst.

 

[Kallisto]

@ Computerbase
Wie Mr.Wifi schon anmerkte passt Framejitter deutlich besser als Framelatenz. Es ist ja in dem sinne keine Zeitdauer zwischen berrechnen eines Frames und anzeigen des selbigen sondern eine Schwankung um einen konstanten Wert.

Der Punkt der mich jedoch viel mehr stört ist die Art und Weise wie ihr die Messergebnisse darstellt! Dadurch das ihr die einzelnen Datenpunkte miteinander verbindet gehen wesentliche Informationen verloren. Sehr viel besser wäre es die einzelnen Datenpunkte lediglich mit einem kleinen x (oder Punkte etc.) zu markieren.

Aus dem so gezeigten Bild kann man nur vermuten, das eines dieser features (Auschlag nach unten + Ausschlag noch oben) auf Grund eines einzelnen verzögerten Bildes entsteht. Es wäre jedoch genauso gut möglich das hier mehrere Bilder verzögert dargestellt werden. Immerhin liegen im Diagramm 43 Datenpunkte innerhalb einer Sekunde (FarCry 3). Wären jetzt jedoch die einzelnen Datenpunkte dargestellt wäre dies möglich. Man denke beispielsweise an die Funktion f(x) = 1 + x für x = [0, 1, 2, 3, 4, 5]. In der Darstellung wie ihr sie verwendet sieht man lediglich eine Linie von (0,1) nach (5,6) laufen. Das dazwischen jedoch drei Werte recht nah am Mittelwert liegen ist nicht ersichtlich.

Sehr schön ist das Problem auch bei Allen Wake der HD 7970 zu sehen. Schwanken jetzt die Berechnungszeiten nun wirklich die ganze Zeit zwischen 19ms und 27ms oder liegen dazwischen auch Werte nahe der Berechnungzeit die dem fps Wert entspricht.

Bei Metro 2033 fällt mir auf das es zwar sehr große Ausreiße zu größeren Berechnungszeiten gibt, jedoch keine dazugehörige kurze Berechnungszeit wie dies bei FarCry 3 zu sehen ist (Man stelle sich drei Steine im gleichen Abstand vor bei denen man den mittleren Stein nach links schiebt -> kurze Berechnungszeit gefolgt von Langer). Es scheinen also unterschiedliche Mechanismen für den Jitter verantwortlich zu sein da hier ja im prinzip einfach ein oder gar mehrere Bilder fehlen (Jetzt denke man wieder an die drei Steine bei denen man den mittleren Stein weg nimmt -> sehr lange Berechnungszeit).

 

[PuppetMaster]

Sie fühlen sich schlecht informiert, gerade weil die Thematik im Test am Wochenende vollständiger wiedergegeben wurde.

Es geht hier in der News doch gar nicht um die Latenzproblematik! Es geht darum, dass ComputerBase ein neues Feature hat. Dazu ein Beispiel und einen Link zum Artikel, für den das erstmalig implementiert wurde. Wo ist denn da das Problem?

 

[Haldi]

Wieso einordnen? Du vermischt statistische Analyse mit der Interpretation. Die technische Begründung liegt bei AMD, dazu fehlt hier allen die Kenntnis.

Ich stelle nur fest, dass man das alles eher hätte darstellen können, wenn man mal von der sturen, geglätteten FPS Betrachtung abgewichen wäre. Mittelwert und Varianz anzugeben sollte sogar der Theologe gelernt haben.

Bah..... als ich meine 3870X2 in meinem PC hatte wusste ich noch nicht mal was Mikro Ruckler sind! Das erste mal gehört davon hab ich beim release der AMD HD5970 oder ein wenig danach. Allerdings nur in solch tollen Test Videos auf Youtube im vergleich von 5870 und 5970 in Stalker Clear Sky. Richtig interessiert hab ich mich dafür erst als ich meine beiden HD7970 im Crossfire hatte und Eyefinity 5760x1080 Auflösung am start hatte. Und als ich mich da kurz vor begin 2012 auf die Suche gemacht habe nach einer definition von Mikrorucklern und Messmethoden bin ich auf einen Thread aus dem jahre 2007 gestossen von GT8800 SLI besitzern... (Jaja das Internet! Denkst du du hast eine tolle neue idee, hatten die schon 10 leute vor dir ) Aber das war auch das einzige was ich zu diesem Thema gefunden habe... Heutzutage liest man ja auf jeder Grösseren Tech seite darüber! Generiert clicks unso... Tja... jedenfalls seit dann heraus gefunden wurde das Skyrim sogar in Single GPU so übelst stockt bei einer HD7950 war dann plötzlich die hölle los! Jede grössere News seite fängt an Framtimes mit zu testen. Aber es fehlt immernoch etwas... und zwar das wissen was Mikroruckler sind! Vorher wurden mikroruckler als stottern oder unflüssiger ablauf des Videos definiert! Nun postet man einen schönen Grafen und alle Regen sich darüber auf "Oh sieht der schrecklich aus" ohne überhaupt zu wissen was er bedeuted! Was momentan noch fehlt ist eine Genaue definition/auswertung dieser Graphen. Das Fraps ein *brauchbares* Programm ist wurde ja schon bewiesen. IMHO einen schritt in die richtige Richtung macht pcper! Sie Nehmen den DVI video out auf, auf einem separaten PC auf eine SSD und sehen so wirklich Frame für Frame was auf dem Bildschirm angezeigt wird! Denn was auf dem Bildschirm angezeigt wird und was in Wirklichkeit von der GPU gerendert wird ist wieder etwas total anderes. Man schaue sich nur das Video aus dem zweiten Test an! PCPer ist jedenfalls auf dem Richtigen weg und ich hoffe das sie bald einmal einen umfassenden Testbericht abliefern und Licht in das Dunkel bringen!
Sehr interessant wäre in diesem Zusammenhang auch eine HiSpeed Camera die mehr als 1000FPS aufnehmen kann vor den Bildschirm zu stellen und zu sehen was passiert!
Naja... egal... ich bin immernoch der Meinung die Optische Methode ist die Beste.... vor dem PC sitzen und sagen Ruckelt / Ruckelt nicht! Ist sowieso nicht jede person gleich empfindlich darauf.

Wie werden den diese "neuen" Diagramme erstellt? Ich vermute das es dafür kein Tool gibt das die Diagramme für ein 3D Programm automatisch generiert, also ist es wohl eher eine Log von einem Tool wie Fraps im Zusammenhang mit einer "manuellen" Auswertung über eine Excel Tabelle oder ein selbst geschriebenes Programm?

Doch Natürlich gibt es das! Fraps frametimes.csv ausgewertet mit:
Sogar Online, zbsp hier von WSGF: http://delphium.mine.nu/grapher_multi.html
Oder Benchmark 3D: http://benchmark3d.com/micro-stutter-checker
Wenn du lieber Offline auswerten möchtest gibt es hier http://frapsforum.com/threads/new-tool-for-viewing-fraps-benchmark-files.2121/ (Wesentlich besser als das Rusische FrapsCalc welches ich vorher verwenden musste)

 

[kinglouy]

@ Computerbase
Wie Mr.Wifi schon anmerkte passt Framejitter deutlich besser als Framelatenz. Es ist ja in dem sinne keine Zeitdauer zwischen berrechnen eines Frames und anzeigen des selbigen sondern eine Schwankung um einen konstanten Wert.

Der dargestellte Wert ist die Dauer der Berechnung, also Zeitabstand zwischen Anfang der Berechnung und Darstellung des Frames. Und genau das ist eine Latenz. Eine Schwankung wird nicht dargestellt, sondern die exakte Dauer der Berechnung. Wenn eine Schwankung dargestellt werden würde, müssten die einzelnen Werte die Differenz zum erwarteten Wert darstellen, bei 60 FPS z.B. die Differenz zu 16.66ms.

 

[Kallisto]

... sondern die exakte Dauer der Berechnung ...

Mit der Aussage wäre ich sehr vorsichtig. Ich bin mir nicht sicher ob nicht schon teile der Graka das nächste Bild rechnen während das letzte Bild von einem Chipsatz über den HDMI/Display-Port/VGA-Anschluss ausgegeben werden (Stichwort Bildwiederholfrequenz).
Abgesehen davon, wenn ich im Labor so ein Signal messe dann spreche ich von Jitter und nicht von einer Latenz.

 

[kinglouy]

Ein Jitter ist aber eine Abweichung vom Durchschnitt bzw. Erwartungswert und nicht der tatsächliche Wert. Und ersteres wird im Diagramm einfach nicht dargestellt.

 

[Kallisto]

Du sagst es und genau das ist es doch was Computerbase mit der Messung zeigen will. Die Abweichung der Frametimes vom fps Wert. Folglich ist Jitter besser als Latenz und wenn sie sich dazu entschließen sollten in folgenden Test von Jitter zu sprechen müssten sie noch die Diagramme umskalieren. Dies hätte ganz nebenbei noch den Reiz durch eine Normierung mit der gemessen fps Zahl die Daten unabhängig von der absoluten fps darzustellen.

In meinem ersten Post ging es mir aber hauptsächlich darum das Problem der Darstellung durch eine Linien anstatt einzelnen Datenpunkten anzusprechen.

 

[kinglouy]

Es ging mir aber darum, dass eben kein Jitter dargestellt wird, sondern die Latenzen. Dir und Mr. Wifi ging es darum, die Bezeichnung im Diagramm zu ändern. Aber in dem aktuellen Diagramm werden eben keine Jitter dargestellt, sondern Latenzen. Dass sie genau diese Abweichungen zeigen wollen ist klar, darum dreht sich ja der Artikel, aber das Diagramm zeigt trotzallem Latenzen und die Abweichungen herauszulesen ist dem Betrachter überlassen.

 

[Emploi]

Wie werden den diese "neuen" Diagramme erstellt? Ich vermute das es dafür kein Tool gibt das die Diagramme für ein 3D Programm automatisch generiert, also ist es wohl eher eine Log von einem Tool wie Fraps im Zusammenhang mit einer "manuellen" Auswertung über eine Excel Tabelle oder ein selbst geschriebenes Programm?

Kannst du mit FRAPS und FRAPPO auch selber machen, sieht dann so aus:



http://www.forum-3dcenter.org/vbulletin/showthread.php?t=537679

 

[Darzerrot]

Ohje, jetzt versteh ich die Argumente paar verblendeter NV-Fanboys, die irgendwas von Rucklern erzählen und deren Kepler ja jetzt soviel toller, cooler, besser ist.

Es kann natürlich auch sein, dass ich total blind bin. Also ich 18 Monate eine 5870 drin hatte und jetzt 6 Monate eine GTX670, also irgendwelche Ruckler bei mehr als 30fps hab ich nicht gesehen, ob AMD oder NV.

CB hat jetzt mal wieder was dolles erschaffen, womit NV wieder mal einen Pluspunkt haben, wieso der Kauf einer NV soviel besser war.

Egal, einfach überlesen, die ganzen Fanboys, ob NV, AMD, Apple usw. kann ich eh nicht mehr lesen, aber zur heutigen Zeit muss ja ein Produkt nicht nur seinen Zweck erfüllen, sondern das Ultimative Prestige Objekt sein, womit der Besitzer direkt ein deutlich besseres Selbstwertgefühl hat und das Leben deutlich aufhellt.

 

[NeoGeo]

in BF3 z.B. gibt es sowas garnicht, da sind die verläufe nahezu perfekt.

Aber auch erst seit November 2012 ... Von Jänner bis November war die HD7XXX in BF3 langsamer und produzierte dazu auch noch Mikroruckler.
Für den BF3 Fix hat AMD also knapp ein Jahr benötigt.

Es kann natürlich auch sein, dass ich total blind bin. Also ich 18 Monate eine 5870 drin hatte und jetzt 6 Monate eine GTX670, also irgendwelche Ruckler bei mehr als 30fps hab ich nicht gesehen, ob AMD oder NV.

... betrifft in erster Linie nur die HD7XXX.
Zu HD5XXX Zeiten war man froh wenn man 20-30 FPS am Schirm hatte

Das Niveau ist mittlerweile höher.

vor dem PC sitzen und sagen Ruckelt / Ruckelt nicht! Ist sowieso nicht jede person gleich empfindlich darauf.

Genau so ist es! Ich merke ab einem Unterschied von 30 ms ein "jittern".
Also bin ich empfindlich drauf.
Gibt auch Leute die im Kino Seekrank werden... (Dazu zähl ich nicht) aber das muß man eben auch "akzeptieren".

Bei kleinerer Auflösung sind die Ausreißer von beiden Grafikkarten wahrscheinlich gleich.

Nein, hab ich schon getestet.
Der VRam Verbrauch sowie die Auflösung spielt keine Rolle und du kommst auf dieselben Differenzen.