Frappo: Frametimeanalyse [Archiv]

pest

2013-01-13, 23:36:17

Hallo,

ich habe an den letzten beiden WEs ein kleines Frametime-Analysetool für Fraps entwickelt.

Die Bedienung ist fast selbsterklärend. Auf "Open" klicken und eine frametime.csv öffnen.

Grundsätzlich arbeitet man in den Einheiten "ms" oder "fps".

Es wird eine kleine Zusammenfassung ausgegeben.

Frames: Anzahl der Frames
Time: Zeit in ms
Min: Minimum und Framenummer des Minimums
Max: Maximum und Framenummer des Maximums
Avg: Durchschnittswert (Mitteltwert bei "ms", Harmonisches Mittel bei "fps")
Mean: Mittelwert
95% CI: approximatives 95% Konfidenzintervall für das Mittel: die Wkt. beträgt 95% , dass das wahre Mittel in diesem Intervall liegt
STDDev: Standardabweichung: Streuungsmaß

Es gibt weiterhin drei Tabs:

"Graph" zeigt den Verlauf:
http://www.abload.de/img/frappo01gjz64.png

"PDF" ist die empirische Dichte (Verteilung der Frames):

Binwidth: Breite der Balken

KDE: Kerndichteschätzung mit Gausskern zur Bandbreite "Bandwidth"
Bandwidth: Bandbreite, größere Werte führen zu stärkerer Glättung

http://www.abload.de/img/frappo02sdyiw.png

"CDF" ist die empirische Verteilungsfunktion (kumulative Verteilung der Frames):

Dabei kann man vorgegebene Interquantile, den Median und eigene Interquantile berechnen,
d.h. das 95% Interquantil gibt an in welchem Bereich sich 95% der Frames
befinden.

http://www.abload.de/img/frappo03ulo56.pnghttp://www.abload.de/img/frappo04scay8.png

Grundsätzliches: Die Min/Max Werte von Fraps sind anders, k.a. warum.
Ich habe das Ganze mit einer 10 Jahre alten Software entwickelt - seltsames Verhalten der Chartkomponenten ist vorprogrammiert

Tipps, Anregungen und Fragen haben hier Platz :)

Gruss

Hübie

2013-01-14, 03:42:47

Könntest du bitte noch die Möglichkeit einführen das Fenster zu gestalten (in die Breite ziehen)? :)

pest

2013-01-14, 20:33:23

Habe ich bereits eingebaut.

Was ich mich allerdings frage ist Folgendes:

Die Quantile werden ja als Anteil an den Frames berechnet, also das 95% Interquantil ist der Bereich in dem 95% der Frames liegen.

Eine andere Möglichkeit wäre das Ganze als Anteil an der Zeit zu betrachten, also den Bereich in dem 95% der Zeit verbracht wird.

samm

2013-01-14, 22:34:30

Damit würden die lahmen Frames stärker gewichtet. Hm, wäre evt. nicht schlecht, oder?

aufkrawall

2013-01-15, 13:09:44

pest

2013-01-15, 15:17:02

kannst du in den adaptive-VSync mal reinzoomen?

Ich möchte noch die ersten Differenzen analysieren um Microruckeln festzustellen.

aufkrawall

2013-01-15, 15:22:31

So?
http://www.abload.de/thumb/peaka3xe0.png (http://www.abload.de/image.php?img=peaka3xe0.png)

Ich teste mal ohne Frame Smoothing.
Hab aber auch schon andere Spiele (DX11 statt 9) getestet, die Standardabweichung ist mit adaptiv immer schlechter.

Edit:
Ohne Frameratesmoothing sieht es noch übler aus und es ruckelt auch sichtbar mehr:
http://www.abload.de/thumb/bl2ofsd3u0c.png (http://www.abload.de/image.php?img=bl2ofsd3u0c.png)

Bei BF3 & HMA ist es nicht dermaßen übel, aber es fühlt sich trotzdem unrunder an.

pest

2013-01-15, 15:40:53

Nee ich meinte eher, ob sich die langsamen/schnellen Frames abwechseln, so sehe ich nur das obere Ende.
Gib mal das 95% Interquantil an, da erkennt man mehr :)

Aber du zeigst mir gerade das ich die untere Grenze der Ordinate ändern muss.

die Standardabweichung ist mit adaptiv immer schlechter.

diese Beurteilung funktioniert aber auch nur hier. Hätte man eine Zeitlang die langsamen und eine weitere Zeit die schnellen Bilder wäre die Standardabweichung genauso groß, aber man hätte weniger unangenehmes Ruckeln

aufkrawall

2013-01-15, 15:54:31

Nee ich meinte eher, ob sich die langsamen/schnellen Frames abwechseln, so sehe ich nur das obere Ende.
Gib mal das 95% Interquantil an, da erkennt man mehr :)

http://www.abload.de/thumb/95iq8ka0v.png (http://www.abload.de/image.php?img=95iq8ka0v.png)

pest

2013-01-15, 15:58:04

narf, schreib doch einfach hin, am Besten im FPS Modus:

TB VSync: 95% in [x fps, y fps]
TB Adaptive: 95% in [x fps, yfps]

Aber man sieht an der CDF sehr schön, das es starke Sprünge und damit zwei Bereche von Frameverteilungen gibt gibt

pest

2013-01-15, 22:50:47

hier mal ein Beispielanalyse mit Frappo v0.02 an einem Crossfire-Sample mit starkem Microruckeln

der Graph verspricht schon nix Gutes, obgleich wir eine Durchschnittsframerate von 38,92fps haben
http://www.abload.de/img/frappo2_01hgunw.png

der CDF-Graph gibt genauere Auskunft
http://www.abload.de/img/frappo2_02zouvz.png
Man sieht bereits am Graphen, dass sich ca. 50% der Frames unter 30 fps befinden (x-Achse: 30 => y-Achse: ~0,5)

Wir berechnen die Wahrscheinlichkeit, dass die Framerate < 30 fps ist: 44,22 % der Frames, aber 74,77% der Zeit wird unter 30 fps verbracht

Zusätzlich habe ich noch einen Graphen mit den 1. Differenzen hinzugefügt. Je kleiner die Werte sind, desto Smoother ist der Verlauf
eine wirklich Beurteilung ist aber z.B. nur im Vergleich zum Durchschnitt möglich, meine HD5870 zeigt hier auch wilde Werte
http://www.abload.de/img/frappo2_03bgan7.png

die Graphen lassen sich jetzt vergrößern und ich habe den Redraw-Button aus dem Tab rausgenommen

MadManniMan

2013-01-15, 23:47:28

Weil ich gerade nix Kluges beizutragen habe, aber interessiert, fasziniert, dankbar und aufmerksam mitlese:

Danke für dieses tolle Tool! Weiter so =)

Leonidas

2013-01-16, 08:25:32

Es wäre vielleicht andenkenswert, aus den ganzen Nebenwerten eine Special-3DC-Framerate zu errechnen, welche man dann der Allgemeinheit um die Ohren hauen kann. Etwas "Normalbürger-freundliches", sprich es muß eine einzige Zahl sein.

Ich lasse mal meine Gedanken schweifen:

1. Variante: Einfacher Durchschnitt der 90% langsamsten Frames.

2. Variante: Einfacher Durchschnitt der 90% langsamsten Frames, wobei alle Frames über 120 fps auf glatt 120 fps festgesetzt werden.

3. Variante: Einfacher Durchschnitt der 90% langsamsten Frames, wobei alle Frames *oberhalb* 50 fps logarithmisch eingedampft werden. Beispiel: 81 fps Ausgangswert, davon gehen 50 fps ab, bleiben 31 fps. Diese gehen durch einen (noch festzulegenden Logarithmus), welche diese 31 fps auf vielleicht 17 fps reduziert. Zusammengezogen mit den 50 fps ergibt der Ausgangswert von 81 fps dann 67 fps, die in die Durchschnittsbildung eingehen.

In allen Fällen geht es um die Betonung der Unterschiede in den besonders niedrigen Frameraten. Zudem wird damit den Herstellern auch die Option genommen (wichtig!!!), durch besonders hohe Frameraten in einigen schnellen Sequenzen den Durchschnitt schnell nach oben zu drücken, obwohl es keine Verbesserung in den langsamen Sequenzen gibt.

Andere Ideen hierzu?

pest

2013-01-16, 09:57:24

in welchem Frameratenbereich wird 95% der Zeit verbracht (muss ich noch einbauen)

dadurch erhalten die langsamen Frames größere Gewichtung und die besonders schnellen eine kleinere.

es bringt nicht viel zu wissen, das xx% der Frames kleiner als 30fps sind, wenn diese sehr langsam sind (sieht man ja auch an meinem letzten Post).

Leonidas

2013-01-16, 11:20:28

in welchem Frameratenbereich wird 95% der Zeit verbracht (muss ich noch einbauen)

dadurch erhalten die langsamen Frames größere Gewichtung und die besonders schnellen eine kleinere.
.

Korrekt, hat aber IMO noch keine ausreichend hohe Schlagkraft. Nach wie vor ist es möglich, mit Steigerungen von 100-fps-Frameraten auf 120 fps das ganze deutlich nach oben zu drücken, obwohl in den langsamen Bereichen sich nix ändert. Da würde erst meine Variante 3 wirklich greifen können.

Wenn wir schon einmal ein so tolles Tool haben, sollten wir es auch richtig machen und uns auf eine wirklich schlagkräftige Formel einigen, die alle Probleme abdeckt.

Hübie

2013-01-16, 12:38:11

Ähm. Bedenkt ihr aber auch dass niemand mit 30 fps spielen möchte weil es da, in 80% der Spiele, eh schon zu zähem Spielfluss kommt? Und ist dir bewusst welchen Aufwand dies bedeute? ;D Wir bräuchten erst mal einen pool an Mitgliedern mit verschiedener Hardware, welche aber die gleichen Spiele nutzen und sich savegames teilen. Und so ganz verstehe ich nicht warum du die fps normieren möchtest.
Ich habe ein grundsätzliches, globales framerate-limit von 118 gesetzt, da alles darüber Unsinn ist. Ich stelle jedoch fest dass es in bestimmten Intervallen zu deutlich über 118 fps kommt und der Treiber diese erst im nächsten Frame abfängt... eigenartig.

samm

2013-01-16, 13:20:32

Wenn wir schon einmal ein so tolles Tool haben, sollten wir es auch richtig machen und uns auf eine wirklich schlagkräftige Formel einigen, die alle Probleme abdeckt.Sowas wäre mMn keine Kernaufgabe des Tools, welches nur die Frametimes zu verwerten hat, netterweise sogar mit konfigurierbarem statistischem Vorgehen. Sondern das wäre eine 3DC-eigene Wertung, weil das Resultat eben nicht statistisch logisch entsteht, sondern aus einer Formel, die je nach frametime anhand arbiträr bestimmter Grenzen unterschiedlich gewichtet , mit dem Ziel, einen konsumfreundlichen "3DC-Performanceindex" o.ä. daraus zu generieren.
Dass es "alle Probleme abdeckt" ist ausserdem ein unerreichbares Ziel ;)

Das soll nicht heissen, dass man keine entsprechende Formel erarbeiten soll! Das wäre sicher nützlich, bloss imo vom Tool per se zu trennen.

pest

2013-01-16, 13:32:38

Korrekt, hat aber IMO noch keine ausreichend hohe Schlagkraft. Nach wie vor ist es möglich, mit Steigerungen von 100-fps-Frameraten auf 120 fps das ganze deutlich nach oben zu drücken, obwohl in den langsamen Bereichen sich nix ändert. Da würde erst meine Variante 3 wirklich greifen können.

Dieses Problem wird ja in der bisherigen Variante abgefangen.

Betrachten wir den festen 95% Intervall an Frames [x fps;y fps]
sind die Frames>y schneller verändert sich y nicht
sind die Frames<x langsamer verändert sich x nicht

Betrachten wir den festen 95% Intervall an Zeit [x fps;y fps]
sind die Frames>y schneller wird x kleiner und y kleiner
sind die Frames<x langsamer wird x kleiner und y kleiner

Vielleicht so ähnlich wie in dem Techreport lösen. 95% Intervall an Frames und Anteil der Zeit kleiner einer Schwelle

Leonidas

2013-01-16, 16:33:44

Nein. Es passiert trotzdem, daß wenn man die schnellen Szenen schneller macht, daß der ds steigt, obwohl die langsamen Szenen nicht profitieren.

@ samm: Ja und nein. Ja, weil das Tool im Idealfall keine Vorgaben machen sollte. Nein, weil es die besten Möglichkeit wäre, mal eine sinnvolle fps-Rechnung zu etablieren und es zudem auch gleich ausrechnen zu lassen, anstatt das immer manuell machen zu müssen.

pest

2013-01-16, 16:47:28

Nein. Es passiert trotzdem, daß wenn man die schnellen Szenen schneller macht, daß der ds steigt, obwohl die langsamen Szenen nicht profitieren.

wen interessiert der Durchschnitt? Die Frage ist für mich gerade ob es Sinn macht das Wahrscheinlichkeitsmaß global umschaltbar zu machen, oder ob ich es so lassen soll wie es jetzt ist.

Eine hausbackene Lösung in einer Zahl halte ich nicht für sinnvoll. Das sollte mathematisch Hand und Fuß haben.

Mit der Angabe 95% der Frames im Intervall [a,b] und x% der Zeit unter y fps hat man schon eine gute Vergleichsmöglichkeit.

Tesseract

2013-01-16, 17:01:19

wir wärs damit:

1) frametimes auf "bumpertimes" umrechnen, d.h. jeweils von einem frame mit frametime >17ms bis zum nächsten - das sind dann im prinzip die abstände von einem ruckler zum nächsten.
2) davon den median bestimmen.
(analog dazu müsste es dann halt auch einen modus für 120Hz geben)

das wär dann quasi ein maß für die häufigkeit der ruckler/tears mit (adaptivem) vsync am entsprechneden monitor.

es ist halt kaum möglich in einem zahlenwert das komplette verhalten in jeder situation anzugeben.

pest

2013-01-16, 17:13:14

wir wärs damit:

1) frametimes auf "bumpertimes" umrechnen, d.h. jeweils von einem frame mit frametime >17ms bis zum nächsten - das sind dann im prinzip die abstände von einem ruckler zum nächsten.
2) davon den median bestimmen.
(analog dazu müsste es dann halt auch einen modus für 120Hz geben)

1) wenn es in einem bereich in kurzen abständen ruckelt und in einem anderen gar nicht

2) wenn es den ganzen bereich über in regelmäßigen abständen ruckelt

1) und 2) würden anderen maßzahlen liefern und sich trotzdem scheisse spielen

wenn ich in Frappo P(X<17ms) berechne kommt für das CF Beispiel raus:
"475 Frames >= 17 ms (38,18% Frames, 56,39% Time)" das reicht doch.

Leonidas

2013-01-16, 17:21:19

wen interessiert der Durchschnitt? Die Frage ist für mich gerade ob es Sinn macht das Wahrscheinlichkeitsmaß global umschaltbar zu machen, oder ob ich es so lassen soll wie es jetzt ist.

Eine hausbackene Lösung in einer Zahl halte ich nicht für sinnvoll. Das sollte mathematisch Hand und Fuß haben.

Mit der Angabe 95% der Frames im Intervall [a,b] und x% der Zeit unter y fps hat man schon eine gute Vergleichsmöglichkeit.

Sehe ich entschieden anders. Wir können nicht der Masse eigene komplizierte Rechnung vorsetzen, die einiges Verständnis veraussetzt. Es muß eine einzige Zahl sein. Aber was spricht gegen eine einzige Zahl, wenn wir eine gute Gewichtung herausarbeiten?

Vorschlag: Da es hier sehr verschiedene Ansichten gibt: Wieso nicht alle möglichen Ansätze durch das Tool berechen lassen? Dann sind es eben 10 verschiedene Ergebnisse, soll sich jeder das für sich passende heraussuchen. Wichtig ist, daß die Rechnerei vom Tool übernommen wird und daß man das nicht manuell machen muß. Ich hätte in diesem Fall im übrigen gern meine Variante 3 mit dabei.

Tesseract

2013-01-16, 17:48:46

1) wenn es in einem bereich in kurzen abständen ruckelt und in einem anderen gar nicht

2) wenn es den ganzen bereich über in regelmäßigen abständen ruckelt

1) und 2) würden anderen maßzahlen liefern und sich trotzdem scheisse spielen

das sind halt extremfälle. damit wirst du bei jeder berechnung irgendwo probleme bekommen.
bei berechnungen ohne rücksicht auf die 60/120Hz-schranken hat man hingegen das problem, dass man zwar die performance zwischen karten besser vergleichen kann, der wert aber noch viel weniger mit der subjektiven spielbarkeit übereinstimmt und genau das ist das hauptproblem bei z.B. microrucklern oder "benchmark-optimierungen".

pest

2013-01-16, 19:39:45

naja m.M. nach kann man jetzt schon die meisten wichtigen Informationen rausziehen, und am Wichtigsten genau die Werte die auch in dem Techreport verwendet wurden.

mit dem Anteil an der Zeit habe ich allerdings auch noch ein Problem was die objektive Bewertung des Reports herabsetzt. Wenn wir meinethalben 2 Karten haben die beide 20% der Frames unter 30fps bleiben aber eine Karte davon 30% der Zeit und die andere 50%, sagt das doch nicht, dass Letztere schlechtere ist. Wenn es ruckelt, ruckelt es halt, da ist es praktisch egal wie langsam.

Ich werde mal zwei zusätzliche Kennzahlen in den Risk-Tab packen.

Sehe ich entschieden anders. Wir können nicht der Masse eigene komplizierte Rechnung vorsetzen, die einiges Verständnis veraussetzt.

Vielleicht bin ich da auch betriebsblind aber mit einer Angabe wie: "20% der Frames < 30fps" kann ich mehr anfangen als "Leonidas Variante 3: 12 fps"

pest

2013-01-16, 21:09:49

Ich habe beide Vorschläge implementiert

Tesseract:

std::vector <double>Bumper;
double threshold=17.0; // ms
int last=0;
for (size_t i=1;i<Frames.size();i++) // Frame 0 has time 0
{
double tdiff=Frames[i].time-Frames[i-1].time;
if (tdiff>threshold)
{
if (last>0) Bumper.push_back(Frames[i].time-Frames[last].time);
last=i;
}
}
if (Bumper.size()>0) return Median(Bumper);
else return Frames.back().time; // return total time?!
}

Leonidas3:

double FTA::CalcLeonidas3()
{
size_t i;
std::vector <double>TransFrames;
TransFrames.reserve(Frames.size()-1);

// transform frames
double threshold=50.0; // fps
double scale=5.0;
for (i=1;i<Frames.size();i++)
{
double tdiff=ToFPS(Frames[i].time-Frames[i-1].time);
if (tdiff < threshold) TransFrames.push_back(tdiff);
else TransFrames.push_back(threshold+log( (tdiff-threshold)*scale));
}

// calc 90% quartile
std::sort (TransFrames.begin(), TransFrames.end());
double Q90=QP(TransFrames,0.90);

// calc avg (harmonic mean) for all frames < Q90
double sum=0.0;
for (i=0;i<TransFrames.size();i++)
{
if (TransFrames[i]<Q90) sum+=1.0/TransFrames[i];
else break;
}
return double(i)/sum;

Und ein paar Ergebnisse

BFBC2 HD5870, Avg: 85,79 fps
95% der Frames [54 fps, 144 fps] - 3,3% der Zeit < 50 fps
Tesseract: 82,10 ms
Leonidas3: 54,73 fps

Crysis Core HD3870X2, Avg: 62,24 fps
95% der Frames [32 fps, 157 fps] - 43% der Zeit < 50 fps
Tesseract: 32,30 ms
Leonidas3: 48,48 fps

Cysis Core HD3870X2, Avg: 38,92 fps
95% der Frames [18 fps, 148 fps] - 82% der Zeit < 50 fps
Tesseract: 50,41 ms
Leonidas3: 31,91 fps

Vantage HD3870X2, Avg: 30,87 fps
95% der Frames [26 fps, 48 fps] - 100% der Zeit < 50 fps
Tesseract: 34,48 ms
Leonidas3: 29,79 fps

Es gibt jetzt zwei Möglichkeiten
1. Ich habe eure Vorstellungen nicht korrekt umgesetzt.
2. Die Kennzahlen sind unbrauchbar:

Tesseract: Die erste Crysis Variante ist def. besser spielbar, obgleich sie einen schlechteren Wert liefert.

Leonidas3: BFBC2 ist bei weitem besser als die erste Crysis Variante bei der ~40% der Frames < 50fps. Man könnte aber den Skalenfaktor anpassen.

RLZ

2013-01-16, 21:27:48

Es muß eine einzige Zahl sein. Aber was spricht gegen eine einzige Zahl, wenn wir eine gute Gewichtung herausarbeiten?
Mit einer Zahl kannst du nur eine Konstante beschreiben. Man will aber eine beliebige Funktion beschreiben. Dafür reichen auch nicht 2 Zahlen, wie uns die 3DKaufberatung zu erzählen versucht. Die Variante von Pest ist schon ziemlich gut, wenn man noch irgendwelche verwertbaren Informationen erkennen will.

Wenn du das auf eine einzige Zahl runterbrechen willst, musst du ein Bewertungssystem ähnlich wie Schulnoten einführen. Eine große Aussagekraft hat die Zahl dann aber nicht mehr.

Tesseract

2013-01-16, 21:36:32

wenn ich das richtig sehe berechnest du den median aller frames mit frametime > 17, nicht den median der länge zwischen den bumpers. (dazu musst du bei einem bumper die frametimes addieren bis du jeweils zum nächsten bumper kommst)

als größe ist quasi gemeint wieviele frames im median zwischen 2 bumpern liegen. je größer die zahl umso flüssiger das ganze.

was du momentan berechnest ist um wieviel die frames im median einbrechen wenn sie unter die schwelle fallen. das ist im grunde aber relativ egal. wenn man einen bumper hat wird man den sowieso sehen.

pest

2013-01-16, 21:42:08

Leonidas Variante habe ich falsch, ich habe vergessen den Threshold draufzuaddieren, warte mal

pest

2013-01-16, 21:44:47

wenn ich das richtig sehe berechnest du den median aller frames mit frametime > 17, nicht den median der länge zwischen den bumpers.

Bumper.push_back(Frames[i].time-Frames[last].time);

ist die Länge eines Bumpers (in ms), also alles korrekt

als größe ist quasi gemeint wieviele frames im median zwischen 2 bumpern liegen. je größer die zahl umso flüssiger das ganze.

das wäre jetzt aber die Anzahl der Frames - was gänzlich Anderes?!

edit: Leonidas Ergebnisse korrigiert

Tesseract

2013-01-16, 21:53:13

Bumper.push_back(Frames[i].time-Frames[last].time);

ist die Länge eines Bumpers, also alles korrekt

die absolute länge zwischen bumpern ist entscheidend.

wenn du z.B. (14, 15, 18, 12, 14, 14, 13, 19, 12) hast ist die zeit zwischen den bumpern 18+12+14+14+13 = 71

pest

2013-01-16, 21:57:10

mit "Länge eines Bumpers" meinte ich die Zeit in ms zwischen zwei Rucklern.
Frames[i].time ist der aktuelle Ruckler. Frames[last].time ist der letzte Ruckler (time ist die absolute Zeit!).

Was du da gerade rechnest verstehe ich nicht.

Tesseract

2013-01-16, 22:03:09

achso, ich dachte in Frames liegen die renderzeiten des jeweiligen frames, nicht ihre position auf der zeitskala. dann macht das ganze natürlich gleich viel mehr sinn.

je mehr ich darüber nachdenke, umso mehr komm ich zum schluss, dass die einzige aussagekräftige darstellung ein framezeiten-histogramm ist. :(
so in der art: http://www.forum-3dcenter.org/vbulletin/showpost.php?p=9583953&postcount=6

pest

2013-01-16, 22:13:43

je mehr ich darüber nachdenke, umso mehr komm ich zum schluss, dass die einzige aussagekräftige darstellung ein framezeiten-histogramm ist. :(
so in der art: http://www.forum-3dcenter.org/vbulletin/showpost.php?p=9583953&postcount=6

naja aus dem Histogramm oder der Dichte lässt sich auch alles andere Wesentliche berechnen
der Statistiker sagt: hat man die Dichte einer Zufallsgröße, weiß man alles :)

hier die zweite Crysis Variante mit heftigen Mikrorucklern.
http://www.abload.de/img/frappo2_04vtunk.png

da ist Vantage eigentlich besser
http://www.abload.de/img/frappo2_05csul9.png

Leonidas

2013-01-17, 03:21:08

Vielleicht bin ich da auch betriebsblind aber mit einer Angabe wie: "20% der Frames < 30fps" kann ich mehr anfangen als "Leonidas Variante 3: 12 fps"

Nein, bist Du nicht. Ich kann mit Deiner Angabe auch mehr anfangen. Aber für die Allgemeinheit muß es eine Framerate sein, die wird keine andere Maßeinheit akzeptieren werden.

PS: Kannst Du mal checken, ob in der von Dir implementierten Variante ungefähr folgendes herauskommt:
- Logarithmus nur für den *Anteil* der fps oberhalb von 50 fps.
- Logarithmus sollte so getweakt sein, daß die höchsten möglichen Endwerte bei Richtung 100 fps liegen, d.h. selbst 1 Mill. fps Realwert nicht mehr als 100 fps Endwert erzielt. Realistischeres Beispiel: 80 fps sollten auf ungefähr 75 fps eingedampft werden, 120 fps auf ungefähr 95 fps. Wichtig ist, daß fps-Werte ab 150 fps faktisch nicht mehr belohnt werden dürfen.
- Nicht zu vergessen: Trotzdem nur Durchschnittsbildung der 90% langsamsten Frames

PS2: Das Diagramm ist schön. Kann das Tool alles an Funktionen bieten (ist es im Tool selber drin?) - wird nur um so schlagkräftiger!

pest

2013-01-17, 07:58:01

PS: Kannst Du mal checken, ob in der von Dir implementierten Variante ungefähr folgendes herauskommt:
- Logarithmus nur für den *Anteil* der fps oberhalb von 50 fps.
- Logarithmus sollte so getweakt sein, daß die höchsten möglichen Endwerte bei Richtung 100 fps liegen, d.h. selbst 1 Mill. fps Realwert nicht mehr als 100 fps Endwert erzielt. Realistischeres Beispiel: 80 fps sollten auf ungefähr 75 fps eingedampft werden, 120 fps auf ungefähr 95 fps. Wichtig ist, daß fps-Werte ab 150 fps faktisch nicht mehr belohnt werden dürfen.
- Nicht zu vergessen: Trotzdem nur Durchschnittsbildung der 90% langsamsten Frames

der Logarithmus ist da nicht so der Hit, man hat praktisch einen Hardcut, und Frames leicht über der Grenze werden sogar schneller
Eine Gleichung mit beschränktem Wachstum wäre vielleicht angebracht

PS2: Das Diagramm ist schön. Kann das Tool alles an Funktionen bieten (ist es im Tool selber drin?) - wird nur um so schlagkräftiger!

das habe ich doch aus Frappo rauskopiert :freak:

Spasstiger

2013-01-17, 09:40:14

Zur Erinnerung, ich hatte ja mal den Versuch unternommen, die Frametime-Statistik auf einen Wert runterzubrechen, wobei ich auf mein persönliches Empfinden im Mikroruckler-Tester kalibriert habe: http://www.forum-3dcenter.org/vbulletin/showthread.php?p=6899107#post6899107.
Damit kurzzeitige Nachladeruckler die Statistik nicht verfälschen, begrenze ich die Framedauern auf das Maximum des 99%-Quantils. Am Ende normalisiere ich die Ergebnisse so, dass der normalisierte Durchschnittswert im 99%-Quantil dem Durchschnittswert des 100%-Quantils entspricht.
Mathematisch hat das imo nicht so wirklich Hand und Fuß, weil man sich Szenarien überlegen kann, in denen mein Verfahren unlogische Ergebnisse liefert.

So sieht meine grafische Ausgabe von Matlab beispielsweise aus:
http://www.abload.de/img/1920x1200_vsync_onz9jwh.png
Die mittlere Framerate stelle ich dar, indem ich sekundenweise die Anzahl an Frames bzw. Frametimes bestimme (ganzzahlig abgerundet). Die Punkte dagegen stellen jeweils die momentane Framerate dar bzw. jeweils den Kehrwert der letzten Framedauer.

Ein Codeausschnitt (Matlab):
factor=0.99;
b=0.001;

framedauer = diff(frametimes_ms)/1000;
avg_framedauer = mean(framedauer);
max_framedauer = max(framedauer);
avg_fps = 1/avg_framedauer

% Begrenzung der Framedauer, um kurzzeitige, starke Ruckler zu eliminieren

framedauer_sort=sort(framedauer);
upper_limit=framedauer_sort(floor(factor*length(framedauer)))
framedauer_smoothed=framedauer;
for i=1:length(framedauer)
if framedauer_smoothed(i) > upper_limit
framedauer_smoothed(i) = upper_limit;
end;
end;

avg_framedauer_smoothed = mean(framedauer_smoothed);
max_framedauer_smoothed = max(framedauer_smoothed);
avg_fps_smoothed = 1/avg_framedauer_smoothed

% Framedelay-Methode

framedelay_avg=0.5*sum(framedauer_smoothed.^2)/sum(framedauer_smoothed)
x = framedelay_avg/max_framedauer_smoothed;
y_avg = avg_framedauer_smoothed/max_framedauer_smoothed;
y=((y_avg-1)*b^x+sqrt(b^y_avg)-y_avg*sqrt(b))/(sqrt(b^y_avg)-sqrt(b));
framedauer_felt_delay=real(y*max_framedauer_smoothed);
avg_fps_felt_delay=1/framedauer_felt_delay
avg_fps_felt_delay_norm=avg_fps_felt_delay*avg_fps/avg_fps_smoothed
/EDIT: Mir fällt gerade auf, dass im im Laufe der Zeit von der Standardabweichung als x-Variable abgekommen bin und stattdessen ein mittleres "Framedelay" als x-Variable definiert habe. Die y-Funktion bildet weiterhin den im Link (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=6899107#post6899107) gezeigten Kurvenverlauf über x ab (/EDIT: Fast, der maximale x-Wert ist 0.5 statt 1, dies führt aber trotzdem auf ein normiertes y=1). Mit dem Parameter b lässt sich die Kurve kalibrieren, d.h. Anfangs- und Endpunkt bleiben gleich, aber die Steigung ändert sich.

@Pest: Weißt du zufällig, ob die von mir fett markierte Funktion im Code in der Mathematik einen bestimmten Namen trägt? Es ist schon ein paar Jahre her, dass ich das implementiert habe und weiß nun nicht mehr, was ich mir genau dabei gedacht habe, diese Funktion statt der Standardabweichung zu verwenden. "framedauer_smoothed" ist ein Vektor.
Was die Auswertungen im Thread angeht, war die mit meinem Algorithmus berechnete mittlere gefühlte Framerate immer recht plausibel. Du kannst ja mal meinen Algorithmus gemäß Code mit rein implementieren.

pest

2013-01-17, 10:51:19

Sagt mir nix, das Ganze geht auch schief wenn die Summe 0 ist. Sind Elemente < 0 vorhanden kommt Quatsch raus.

edit:
Also nehmen wir statt 0.5, die Wurzel aus dem Summenquadrat handelt es sich um das Verhältnis zwischen euklidischer und 1-Norm :>

Das ist auch keine Approximation zur Standardabweichung, ich kann dir beliebige Beispiele konstruieren wo deine Berechnung weit unterhalb oder weit überhalb der Standardabweichung liegt.

Wenn ich mir die Mühe mache, dass reinzubauen bitte ein bisschen begründen was das macht und warum das sinnvoll ist. Man kann viel rechnen wenn der Tag lang ist.

hier verstehe ich nur Bahnhof

y=((y_avg-1)*b^x+sqrt(b^y_avg)-y_avg*sqrt(b))/(sqrt(b^y_avg)-sqrt(b));

Spasstiger

2013-01-17, 12:54:09

Sagt mir nix, das Ganze geht auch schief wenn die Summe 0 ist. Sind Elemente < 0 vorhanden kommt Quatsch raus.
Diese beiden Fälle sind bei realen Daten nicht möglich. Es gibt keine negativen Framedauern, weil die Framedauern die positiven Differenzen zwischen den Frametimes sind. Und wenn die Summe 0 ist, dann wäre die Framerate unendlich, was bei realen Daten auch nicht vorkommt.

Das ist auch keine Approximation zur Standardabweichung, ich kann dir beliebige Beispiele konstruieren wo deine Berechnung weit unterhalb oder weit überhalb der Standardabweichung liegt.
Das soll auch gar keine Standardabweichung sein. Es muss bei realen Daten aber ein robusteres Maß als die Standardabweichung sein, sonst hätte ich es vor ein paar Jahren nicht als primäre Variante eingebaut.

hier verstehe ich nur Bahnhof

y=((y_avg-1)*b^x+sqrt(b^y_avg)-y_avg*sqrt(b))/(sqrt(b^y_avg)-sqrt(b));

Das ist diese Funktion (Exponentialfunktion):

http://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=44778&stc=1&d=1358423372

Und deren Kehrwert:
http://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=44779&stc=1&d=1358423372

Über den Parameter b kann man die Krümmung der Kurve ändern, bei b=1 ergibt sich eine Gerade. b nutzt man also zum Kalibrieren der Funktion, ich hab das mit dem Mikroruckler-Tester aus dem Computerbase-Forum gemacht (Download (http://www.computerbase.de/downloads/system/grafikkarten/mikroruckler-tester-fuer-single-gpu/)).
Das mittlere Framedelay nach der im Code fett markierten Formel liegt für reale Frametime-Daten immer zwischen 0.5 * Mittlere Framedauer (Framerate konstant) und 0.5* Maximale Framedauer (extreme Ungleichverteilung der Framedauern), nur in dem Bereich ist auch y definiert.
Die Grundidee ist, dass im schlimmsten Fall die maximale Framedauer den subjekten Framerateneindruck dominiert und im besten Fall die mittlere Framerate dem subjektiven Framerateneindruck entspricht.
Ich hab mir damals die Framedelay-Formel irgendwie hergeleitet, weiß aber nicht mehr wie. Scheint jedenfalls recht robust zu sein für die Anwendung.

pest

2013-01-17, 13:26:33

Das soll auch gar keine Standardabweichung sein. Es muss bei realen Daten aber ein robusteres Maß als die Standardabweichung sein, sonst hätte ich es vor ein paar Jahren nicht als primäre Variante eingebaut.

wie kommst du darauf, dass es robuster ist? Es ist genauso empfindlich gegen Ausreißer.

ich halte nix von Homebrew Lösungen wenn es ein reichhaltiges Angebot (http://de.wikipedia.org/wiki/Streuung_%28Statistik%29) gibt.

Spasstiger

2013-01-17, 13:39:28

Ok, dann ist meine Idee für einen einzelnen Frameratenwert - wie z.B. von Leonidas gewünscht - eine Maßzahl für die Streuung zu ermitteln und diese über eine Exponentialfunktion einem Frameratenwert zuzuweisen. Best Case - konstante Framerate - bedeutet, dass die gefühlte Framerate der mittleren Framerate entspricht. Im Worst Case - maximale Streuung, z.B. 0 ms Framedauer und 100 ms Framedauer im Wechsel, was bei Alternate Frame Rendering mit 2 GPUs bedeutet, dass die Frames beider GPUs jeweils denselben Zeitpunkt repräsentieren - entspricht die gefühlte Framerate der minimalen Framerate.

/EDIT: Mir fällt wieder ein, was an meinem Maß für die Streuung (scheinbar) besser war als an der Standardabweichung. Gesetzt den Fall, dass Alternate Frame Rendering mit 2 GPU maximal ungünstig rendert und auf beiden GPUs jeweils die Frames für den gleichen Zeitpunkt rendert. Dann betragen die Framedauern z.B. im Wechsel 0 ms und 50 ms (Frametimes: 0 ms, 0 ms, 50 ms, 50 ms, 100 ms, 100 ms, 150 ms, 150 ms, ...). Das ist natürlich ein Worst-Case-Fall und es ist völlig klar, dass die zweite GPU gar keinen Gewinn bringt und alleine die maximale Framedauer (50 ms) die gefühlte Framerate (20 fps) bestimmt, auch wenn sich rein rechnerisch eine Durchschnittsframerate von 40 fps ergibt.
Nehmen wir nun drei unterschiedlich lange Ausschnitte aus einer solchen Framedauerfolge:
d1=(0, 50)
d2=(0, 50, 0, 50)
d3=(0, 50, 0, 50, 0, 50, 0, 50, 0)
Alle Folgen repräsentieren dasselbe Verhalten.
Vergleichen wir die Streuungsmaße:
Mittleres Framedelay nach Spasstiger: d1 => 25, d2 => 25, d3 => 25
Standardabweichung mit 1/(n-1) als Vorfaktor: d1 => 35,355, d2 => 28,868, d3 => 26.7261

Das Problem war für mich, dass die Standardabweichung von der Länge der Datenfolge abhängig war. Aber dieses Problem lässt sich natürlich lösen, wenn man einfach die alternative Definition der Standardabweichung mit 1/n als Vorfaktor nimmt. Dann kommt im Beispiel immer 25 raus. Normiert auf die maximale Framedauer entspricht das einem Wert von 0.5 wie auch bei meinem Maß. Im Best-Case-Fall (konstante Framerate) ergibt sich bei der Standardabweichung halt ein normierter Wert von 0, während sich bei meinem Maß 0.5* Mittlere Framerate ergibt. Meine y-Funktion passt mit der Standardabweichung als Streuungsmaß also nicht.

P.S.: Bei der Darstellung des Frameratenverlaufs in Frappo würde ich die Punktedarstellung für die Kehrwerte der Framedauern wählen und dediziert eine mittlere Framerate als Moving Average über einen bestimmten Zeitraum (z.B. 1 Sekunde) darstellen. Sonst ist das Diagramm bei Aufzeichnungen von Mikrorucklern sehr unübersichtlich.
Zur Erinnerung, so sieht meine Darstellung aus:
http://www.abload.de/img/1920x1200_vsync_onz9jwh.png
Die blaue Kurve repräsentiert die Werte, die Fraps im Spiel live anzeigen würde (kein Moving Average, wäre aber schöner).

Bei deiner Darstellung sieht es dagegen so aus:
http://www.abload.de/img/frappojyjg5.png

pest

2013-01-17, 15:45:16

Ok, dann ist meine Idee für einen einzelnen Frameratenwert - wie z.B. von Leonidas gewünscht - eine Maßzahl für die Streuung zu ermitteln

da es schon angegeben wird, würde ich einen interquantilsabstand nehmen (vielleicht 50% oder 90%).

und diese über eine Exponentialfunktion einem Frameratenwert zuzuweisen. Best Case - konstante Framerate - bedeutet, dass die gefühlte Framerate der mittleren Framerate entspricht. Im Worst Case - maximale Streuung, z.B. 0 ms Framedauer und 100 ms Framedauer im Wechsel, was bei Alternate Frame Rendering mit 2 GPUs bedeutet, dass die Frames beider GPUs jeweils denselben Zeitpunkt repräsentieren - entspricht die gefühlte Framerate der minimalen Framerate.

was ist maximale Streuung? also quantitativ

Vergleichen wir die Streuungsmaße:
Mittleres Framedelay nach Spasstiger: d1 => 25, d2 => 25, d3 => 25
Standardabweichung mit 1/(n-1) als Vorfaktor: d1 => 35,355, d2 => 28,868, d3 => 26.7261

einfach mehr Datenpunkte nehmen.

Aber dieses Problem lässt sich natürlich lösen, wenn man einfach die alternative Definition der Standardabweichung mit 1/n als Vorfaktor nimmt.

Es gibt keine "alternative Definition". Du kennst den Erwartungswert der Stichprobe nicht, welcher zusätzlich geschätzt wurden muss.

P.S.: Bei der Darstellung des Frameratenverlaufs in Frappo würde ich die Punktedarstellung für die Kehrwerte der Framedauern wählen und dediziert eine mittlere Framerate als Moving Average über einen bestimmten Zeitraum (z.B. 1 Sekunde) darstellen. Sonst ist das Diagramm bei Aufzeichnungen von Mikrorucklern sehr unübersichtlich.

ich finde den Framegraph generell Unsinn, du kannst außerdem zoomen! oder einfach das Bild auf 1920 ziehen :)

Aber so eine MA-Framerate wollte ich noch einbauen, es fehlen außerdem noch ein paar Dinge und Rechtschreibfehler korrigieren. Tesseracts Code rausnehmen usw..

MadManniMan

2013-01-17, 17:20:50

Die meiste Zeit verstehe ich gerade nur Bahnhof, darum nur eine kurze Zwischenfrage: der "Risk"-Tab ... äh ... nee, erledigt sich gerade :D

Kann man Dich flattrn?

Godmode

2013-01-17, 18:50:57

Danke für das Tool!

Hab mal in Diablo 3 mit verschiedenen Settings gemessen. Alles unspielbar, bis auf das wo ich den Limiter ausschalte und VSync auf die 1/2 Refreshrate stelle.
Hab die Frametimes angehängt, falls es jemanden interessiert.

pest

2013-01-17, 19:30:59

Kann man Dich flattrn?

ich bin schon vergeben :(

Hab mal in Diablo 3 mit verschiedenen Settings gemessen. Alles unspielbar, bis auf das wo ich den Limiter ausschalte und VSync auf die 1/2 Refreshrate stelle.

also warum es "unspielbar" ist weiß ich nicht, Tearing? Die Graphen sind mehr oder minder perfekt.

pest

2013-01-17, 20:07:55

- Logarithmus sollte so getweakt sein, daß die höchsten möglichen Endwerte bei Richtung 100 fps liegen, d.h. selbst 1 Mill. fps Realwert nicht mehr als 100 fps Endwert erzielt. Realistischeres Beispiel: 80 fps sollten auf ungefähr 75 fps eingedampft werden, 120 fps auf ungefähr 95 fps. Wichtig ist, daß fps-Werte ab 150 fps faktisch nicht mehr belohnt werden dürfen.
- Nicht zu vergessen: Trotzdem nur Durchschnittsbildung der 90% langsamsten Frames

ich habe die Funktion etwas getweakt.

Der Ansatz für Frames > 50 fps ist:

f(x)=50 + 70*(1-exp(-s*(x-50)) mit s=0.015

-die Funktion liefert für f(120)=95.5 und f(80)=75.3
-die Funktion hat eine Kapazität von 120

Problem ist für x > 50 und x < 57 liefert die Funktion etwas größere Frameraten, analog zur vorrigen Funktion.

pest

2013-01-17, 22:03:18

@Spasstiger

ich habe ein Problem mit dem Moving Average

Ist die Darstellungseinheit [ms] ist alles i.O.
http://www.abload.de/img/frappo3_01g1u9a.png

Ist die Darstellungseinheit [fps] und ich berechne die Durchschnittsfps (die Kurve nähert sich dem Avg-Fps Wert) passiert natürlich Folgendes
http://www.abload.de/img/frappo3_02oou2x.png

Mathematisch korrekt nähert sich die Kurve dem Mittelwert
http://www.abload.de/img/frappo3_03ank1z.png

Ich habe eine Funktion hinzugefügt die feststellt ob die Frames mit AFR2 gerendert wurden und es gibt eine kleine Bewertung, ein paar Beispiele:

Beispiele von oben:
BFBC2 HD5870: Rendering: single GPU
Crysis Core 1 HD3870X2: Rendering: possible AFR2 (5,3), Offset: medium
Crysis Core 2 HD3870X2: Rendering: possible AFR2 (19,6), Offset: large
Vantage HD3870X2: Rendering: possible AFR2 (2,5), Offset: small
COD4 HD3870X2 CF-Off: Rendering: single GPU

Spasstiger

2013-01-17, 22:27:16

@Pest: Beziehe das Moving Average mal auf einen bestimmten Zeitraum, nicht auf eine bestimmte Anzahl von Frames. Hat deine x-Achse eigentlich eine Zeiteinheit? Wenn nein, solltest du auch das verbessern.
Einfaches Beispiel, warum Mitteln der momentanten Framerate in die Hose geht:
Deine Frametimes sind 0 ms, 20 ms, 70 ms und 90 ms. Du hast also die drei Framedauern 20 ms, 50 ms und wieder 20 ms mit einem Mittelwert von 90 ms / 3 = 30 ms, was einer mittleren Framerate von 33,33 fps entspricht.
Berechnet man die momentanen Frameraten als Kehrwerte der Framedauern, ergeben sich 50 fps, 20 fps und wieder 50 fps. Der Mittelwert davon wäre 40 fps, was aber eben nicht die durchschnittliche Framerate (33,333 fps) ist. Die durchschnittliche Framerate ist stets die Anzahl der gerenderten Frames geteilt durch die gesamte Renderzeit. Der physikalische Bezug zur Zeit ist essentiell.

was ist maximale Streuung? also quantitativ
Quantitativ? Kommt halt auf das Maß an.
Qualitativ ist es für meine Bestimmung der gefühlten Framerate über die Exponentialfunktion der Fall, wenn nur noch die maximale Framedauer sichtbar ist, obwohl die mittlere Framedauer darunter liegt. Also z.B. wenn sich beim Alternate Framerate Rendering die Zeitpunkte der Frames beider GPUs exakt decken und beide GPUs die identischen Frameinhalte berechnen. Die Standardabweichung der Framedauern geteilt durch die maximale Framedauer kommt imo als Maß in Frage, die maximale Streuung entspricht dann 0,5. Man sollte aber vorher noch Ausreißer rausrechnen, z.B. indem man nur das 99%-Quantil heranzieht.

pest

2013-01-17, 22:43:34

@Pest: Beziehe das Moving Average mal auf einen bestimmten Zeitraum, nicht auf eine bestimmte Anzahl von Frames. Hat deine x-Achse eigentlich eine Zeiteinheit? Wenn nein, solltest du auch das verbessern.
Einfaches Beispiel, warum Mitteln der momentanten Framerate in die Hose geht:
Deine Frametimes sind 0 ms, 20 ms, 70 ms und 90 ms. Du hast also die drei Framedauern 20 ms, 50 ms und wieder 20 ms mit einem Mittelwert von 90 ms / 3 = 30 ms, was einer mittleren Framerate von 33,33 fps entspricht.
Berechnet man die momentanen Frameraten als Kehrwerte der Framedauern, ergeben sich 50 fps, 20 fps und wieder 50 fps. Der Mittelwert davon wäre 40 fps, was aber eben nicht die durchschnittliche Framerate (33,333 fps) ist. Die durchschnittliche Framerate ist stets die Anzahl der gerenderten Frames geteilt durch die gesamte Renderzeit. Der physikalische Bezug zur Zeit ist essentiell.

Ach man :)
Du musst mir nicht erklären was ich tue ;)

die Basiseinheit ist Frames, das will ich aber noch variabel machen
ich wollte wissen, was von Beidem ich nehmen soll: ein Moving-Average ist ein Moving-Average, dem sind physikalische Einheiten egal

Qualitativ ist es für meine Bestimmung der gefühlten Framerate über die Exponentialfunktion der Fall, wenn nur noch die maximale Framedauer sichtbar ist, obwohl die mittlere Framedauer darunter liegt.

das Problem an deiner Variante ist immer wenn es zwei Bereiche gibt deren Framezeiten innerhalb der Bereiche konstant, aber zwischen Ihnen stark unterschiedliche sind. Die Streuung ist dabei rel. stark obgleich die gefühlte Framerate wohl in der Nähe des Avg-Wertes liegt.

Spasstiger

2013-01-17, 22:54:17

die Basiseinheit ist Frames, das will ich aber noch variabel machen
ich wollte wissen, was von Beidem ich nehmen soll: ein Moving-Average ist ein Moving-Average, dem sind physikalische Einheiten egal
Wie gesagt, es kommen nur sinnvolle Werte raus - solche, die man z.B. auch anhand des Framecounters im Spiele sehen würde -, wenn man den Moving Average über der Zeit bildet. Die Zeit kann natürlich auch abgetastet sein, aber eben in regelmäßigen Abständen und nicht in unregelmäßigen Abständen wie du es tust.
In meinen Signalverarbeitungsvorlesungen haben wir den Moving Average immer über konstanten Zeitintervallen durchgeführt, nicht über variablen Zeitintervallen. D.h. benachbarte Samples müssen zeitlich immer gleich weit voneinander entfernt sein.
Als Mathematiker mag dir zwar deine Variante auch legitim erscheinen, aber ich sage dir als Nachrichtentechniker einfach nur, was in der Praxis sinnvoll ist.

Mein Vorschlag: Schau dir zu jeder Frametime die vergangenen x Milisekunden an und zähle in diesen x Milisekunden die Anzahl an Frametimes (= dargestellte Frames). Diese Anzahl teilst du dann durch die x Milisekunden. Beim Zählen musst du nur die Frametime 0 außen vor lassen.

das Problem an deiner Variante ist immer wenn es zwei Bereiche gibt deren Framezeiten innerhalb der Bereiche konstant, aber zwischen Ihnen stark unterschiedliche sind. Die Streuung ist dabei rel. stark obgleich die gefühlte Framerate wohl in der Nähe des Avg-Wertes liegt.
/EDIT: Hatte es erst falsch verstanden. In dem Fall hat man natürlich gefühlt prinzipiell zwei Eindrücke, die man vielleicht auch dediziert betrachten sollte.

pest

2013-01-17, 23:03:51

du musst dir schon durchlesen was ich schreibe imo, oben sind beide Varianten dargestellt. Die zweite von oben, macht genau das was du schreibst.

Spasstiger

2013-01-17, 23:10:01

Du trägst alles über den Framenummern und nicht über der Zeit auf, von daher ist das für mich alles Käse. Wir betrachten hier ein Zeitverhalten, deshalb gehört an die x-Achse auch eine Zeiteinheit.
Imo ist es völliger Unfug, dass der Moving Average der Framerate für alle Werte steigt sinkt, wenn man das Fenster vergrößert. Ein größeres Fenster sollte nur eine stärkere Glättung bewirken. Das Spiel läuft ja nicht ruckeliger, wenn man länger misst.

pest

2013-01-17, 23:25:19

links mit Einheit [Frames], Rechts mit Einheit [Zeit in s] - wird halt ein bisschen gestaucht und gestreckt :?

http://www.abload.de/img/frappo3_02oou2x.png http://www.abload.de/img/frappo3_04ivrkt.png

Imo ist es völliger Unfug, dass der Moving Average der Framerate für alle Werte steigt sinkt, wenn man das Fenster vergrößert. Ein größeres Fenster sollte nur eine stärkere Glättung bewirken. Das Spiel läuft ja nicht ruckeliger, wenn man länger misst.

er sinkt auch nicht, er liegt nur weit unterhalb der Mitte beider "Ränder" und das liegt an dem fiesen CF-Beispiel, schau mal auf den Wert für Avg und Mean.

Spasstiger

2013-01-17, 23:30:54

links mit Einheit [Frames], Rechts mit Einheit [Zeit in s] - wird halt ein bisschen gestaucht und gestreckt :?
Hast du denn auch den Moving Average über der Zeit berechnet? Sieht ja nicht so aus.
Deine Fenstergröße ist z.B. 1 Sekunde, d.h. du bildest stets über dieser Sekunde die durchschnittliche Framerate (Anzahl an Frames in einer Sekunde geteilt durch eine Sekunde). Wenn du näher an der mathematischen Definition des MA bleiben willst: Taste dein Signal in gleichen zeitlichen Abständen ab und bilde dann den Mittelwert über x Samples. Bislang liegen ja die benachbarten Samples zeitlich gesehen mal weiter voneinander weg, mal näher beieinander. Genau da liegt der Hunde begraben.
Siehe auch Wikipedia:
http://upload.wikimedia.org/math/f/2/a/f2aadae9475814c072d7b8cf7b195c23.png (http://de.wikipedia.org/wiki/Gleitender_Mittelwert)
Wie man unschwer erkennen kann, sind die zeitlichen Abstände zwischen den Samples, über die der MA gebildet wird, immer gleich groß! Und wie weiter oben angeführt, darfst du auch nie die momentanen Frameraten mitteln, sondern musst immer über die Framedauern gehen und am Ende den Kehrwert bilden, um auf eine Framerate zu kommen.

pest

2013-01-17, 23:48:29

1. die durchschnittliche geglättete Framerate sollte sich dem Avg-Wert annähern - das tut sie (letzte beiden Bilder)

Hast du denn auch den Moving Average über der Zeit berechnet? Sieht ja nicht so aus.
Deine Fenstergröße ist z.B. 1 Sekunde, d.h. du bildest stets über dieser Sekunde die durchschnittliche Framerate (Anzahl an Frames in einer Sekunde geteilt durch eine Sekunde).

kann man machen

Wenn du näher an der mathematischen Definition des MA bleiben willst: Taste dein Signal in gleichen zeitlichen Abständen ab und bilde dann den Mittelwert über x Samples. Bislang liegen ja die benachbarten Samples zeitlich gesehen mal weiter voneinander weg, mal näher beieinander. Genau da liegt der Hunde begraben.

Da liegt gar nix begraben. Eine gewisse Anzahl von Frames brauchen eine gewisse Anzahl von mittlere Zeit (in ms). Davon berechne ich die Framerate.

double sum=(myFTA.Frames[i+tau].time - myFTA.Frames[i-tau-1].time)/double(2*tau+1);
sum=1000.0/sum;

Siehe auch Wikipedia:
http://upload.wikimedia.org/math/f/2/a/f2aadae9475814c072d7b8cf7b195c23.png (http://de.wikipedia.org/wiki/Gleitender_Mittelwert)
Wie man unschwer erkennen kann, sind die zeitlichen Abstände zwischen den Samples, über die der MA gebildet wird, immer gleich groß!

das t ist nur eine Variable

Und wie weiter oben angeführt, darfst du auch nie die momentanen Frameraten mitteln, sondern musst immer über die Framedauern gehen und am Ende den Kehrwert bilden, um auf eine Framerate zu kommen.

Und noch mal, das sind genau die beiden Beispiele die ich oben aufgeführt habe. Ich habe beides getestet und wollte bloß von dir wissen was ich nehmen soll. Das diese Frage bei dir impliziert, dass ich nicht wüsste was ich tue, liegt vielleicht an mir.

Und ja, das Thema ist jetzt beendet.

Godmode

2013-01-18, 01:18:17

ich bin schon vergeben :(

also warum es "unspielbar" ist weiß ich nicht, Tearing? Die Graphen sind mehr oder minder perfekt.

Weiß nicht es tritt jede Sekunde ein Ruckler auf, aber das liegt wohl an D3, das einfach unglaublich verbuggt ist. Will hier aber gar net zu sehr OT reden.

Werde vielliecht nochmal mit Single GPU testen ob es da genau so auftritt.

Finde das Tool super!

pest

2013-01-18, 08:21:12

Werde vielliecht nochmal mit Single GPU testen ob es da genau so auftritt.

sag das doch gleich, interessant. Frappo sagt bei "Vsync-standard-Limiter@Off"

Rendering: possible AFR2 (3,0), Offset: small

:)

RavenTS

2013-01-22, 14:56:44

Wird das Tool eigentlich mal was fürs 3DCenter bzw. unter 3D-Tools auch angeboten werden?

Wäre doch ne feine Sache...

Godmode

2013-01-22, 15:20:46

sag das doch gleich, interessant. Frappo sagt bei "Vsync-standard-Limiter@Off"

Rendering: possible AFR2 (3,0), Offset: small

:)

Kannst du mir verraten was das heißen soll? AFR2 kenne ich, aber was ist das in den Klammern, (3,0)?

pest

2013-01-22, 16:02:02

Hallo,

dich wollte ich sowieso mal ansprechen. Vielleicht kannst du mir mal Quad-SLI Frametimes zukommen lassen.
Einfach die "frametime.csv" hier in einen Spoiler packen.

Die Zahl gibt einen Faktor an (das ist das Offset). In der neuen Version steht statt 3,0 dann 3xx %.
Single-GPU Karten haben üblicherweise ~100%, "gutes" AFR2 105-110%. Mieses AFR2 3000%. Die Abstufungen habe ich Anhand ein paar CF-Beispiele gemacht. Die Schwelle für AFR2 liegt dabei bei 200%, medium bei 500%, large bei 1500%

Godmode

2013-01-22, 16:08:12

aufkrawall

2013-01-22, 16:47:46

Au, adaptives Vsync bei Nvidia ist echt im Arsch (Borderlands 2):
TB Vsync:
http://www.abload.de/thumb/tb8vruc.png (http://www.abload.de/image.php?img=tb8vruc.png)

Adaptives:
http://www.abload.de/thumb/adaptivmhqch.png (http://www.abload.de/image.php?img=adaptivmhqch.png)

Das eignet sich so wohl ganz gut für nen Bugreport. :freak:
Nützliches Tool.
Oder auch nicht, es liegt am erzwungenen SGSSAA per Custom Bit.
Ohne sind die Frametimes mit adaptivem Vsync recht gut. Man kann es aber auch mit beidem zusammen noch spielen, läuft immerhin noch deutlich weicher als ohne Vsync bei vergleichbaren fps.
Hitman Absolution läuft eigentlich auch genau so gut mit adaptivem Vsync, da hab ich die Standardabweichung überbewertet. Frametimes sehen jedenfalls so übel nicht aus.
Nur bei BF3 stimmt irgendwas nicht, aber da ruckelt es selbst mit normalem Vsync. Tippe auf einen Bug vom 310er Treiber. Mal die nächste Serie abwarten.
Crysis 2 DX11 und Crysis 1 DX9 (+SGSSAA per Custom Bit) laufen mit adaptivem Vsync auch sehr smooth, keine Auffälligkeiten.

Adaptiv find ich zwar mit Single-GPU recht sinnfrei, mit SLI spart man sich den TB aber lieber.

Godmode

2013-01-22, 16:57:31

Oder auch nicht, es liegt am erzwungenen SGSSAA per Custom Bit.
Ohne sind die Frametimes mit adaptivem Vsync recht gut. Man kann es aber auch mit beidem zusammen noch spielen, läuft immerhin noch deutlich weicher als ohne Vsync bei vergleichbaren fps.
Hitman Absolution läuft eigentlich auch genau so gut mit adaptivem Vsync, da hab ich die Standardabweichung überbewertet. Frametimes sehen jedenfalls so übel nicht aus.
Nur bei BF3 stimmt irgendwas nicht, aber da ruckelt es selbst mit normalem Vsync. Tippe auf einen Bug vom 310er Treiber. Mal die nächste Serie abwarten.
Crysis 2 DX11 und Crysis 1 DX9 (+SGSSAA per Custom Bit) laufen mit adaptivem Vsync auch sehr smooth, keine Auffälligkeiten.

Adaptiv find ich zwar mit Single-GPU recht sinnfrei, mit SLI spart man sich den TB aber lieber.

Das könnte dann wohl bei mir bei D3 auch reinspielen, da ich dort ebenfalls Custombits für AA verwendet hab, IIRC.

aufkrawall

2013-01-22, 17:34:26

Das könnte dann wohl bei mir bei D3 auch reinspielen, da ich dort ebenfalls Custombits für AA verwendet hab, IIRC.
D3 ist imho ruckelig by design, ein ziemlicher Code-Schrotthaufen.
Für Frametime-Bewertungen daher wohl eher unbrauchbar.
Aber müsstest du halt mal vergleichen, obs zwischen normalem & adaptivem Vsync irgendwelche großartigen Unterschiede bei den Frametimes gibt.

aufkrawall

2013-01-24, 11:50:08

Bei BF3 wird es wohl auch kein genereller Treiberbug bezüglich Vsync sein, ich hatte bei einem neuen Versuch mit normalem in-game Vsync jetzt akzeptable Frametimes (vll brauchte Treiber mal nen Neustart, keine Ahnung). Alles prerendered Frames 1:
http://www.abload.de/thumb/bf3ueqsf.png (http://www.abload.de/image.php?img=bf3ueqsf.png)

BF3 adaptiv:
http://www.abload.de/thumb/bf3aelr18.png (http://www.abload.de/image.php?img=bf3aelr18.png)

Edit: Ok, lag an SLI. Mit sGPU sind die Frametimes bei adaptivem Vsync wie geleckt:
http://www.abload.de/thumb/bf3avsyncsgpucioqq.png (http://www.abload.de/image.php?img=bf3avsyncsgpucioqq.png)

Crysis 2 adaptiv (SLI):
http://www.abload.de/thumb/c2vyrtl.png (http://www.abload.de/image.php?img=c2vyrtl.png)

Cryengine 3 ftw. Das läuft wunderbar smooth bei 60fps und der geniale Motion Blur tut sein Übriges.

Mr. Lolman

2013-01-24, 16:14:29

Ich kann mir schwer vorstellen, dass man, angesicht solcher Frametimes, mit SLI überhaupt irgendeinen merkbaren Mehrwert hat.

aufkrawall

2013-01-24, 16:24:03

;D
Mr. Lolman merkt die Schwankungen zwischen 16 und 18ms, oder was für einen BS erzählt er gerade...

Mr. Lolman

2013-01-24, 16:31:40

Na, das arge SLI ruckeln mein ich.... (BF3 adaptiv)

aufkrawall

2013-01-24, 16:35:16

Das wird wohl ein Bug sein, du siehst ja, dass Crysis 2 so nicht ruckelt.
Mit normalem Vsync/Framelimiter ruckelt BF3 mit SLI jedenfalls nicht.

pest

2013-01-24, 18:03:53

Ihr redet von unterschiedlichen Dingen

kannst du die BF3 csv mal in einen Spoiler packen?

aufkrawall

2013-01-24, 18:10:42

Ihr redet von unterschiedlichen Dingen

Falls er die Ausschläge bei BF3 mit normalem Vsync & SLI meint:
Gut, optimal ist was anderes. Das Spiel fühlt sich aber auch bei Single-GPU mit Vsync nicht wirklich flüssig an, einfach furchtbar.
Deshalb greif ich dabei mittlerweile lieber gleich zum fps-Limiter.
Ich behalte die Frametimes aber mal mit zukünftigen Treibern im Blick.

kannst du die BF3 csv mal in einen Spoiler packen?

pest

2013-01-24, 18:21:35

Die nichtadaptive Variante hat "trotzdem" Microruckeln: Offset 120%

822 Frames < 60 fps (48,78% Frames, 51,36% Time)
863 Frames >= 60 fps (51,22% Frames, 48,64% Time)

95,00% Frames in [52,70 fps;70,34 fps]: 17,64 fps
2,50% < 52,70 fps, 2,50% > 70,34 fps

adaptiv dämpft das Microruckeln: Offset: 100%, allerdings ist die Frameverteilung nicht mehr so schön, dürfte sich also unsmoother spieler

361 Frames < 60 fps (46,88% Frames, 56,47% Time)
409 Frames >= 60 fps (53,12% Frames, 43,53% Time)

95,00% Frames in [30,96 fps;191,46 fps]: 160,50 fps
2,50% < 30,96 fps, 2,50% > 191,46 fps

La Junta

2013-01-24, 20:15:33

Nettes Tool , danke pest .
Hab nun auch mal paar Benches durchlaufen lassen und zwar BF3 auf vollem 64iger Server, Azadi Palace (Conquest large) .
CPU : I72600 @ 3900MHZ
GPU : HD7970 @ 1200MHZ / 1600MHZ

Settings waren diese : http://www.abload.de/thumb/bf3_2013_01_24_18_50_6ss82.jpg (http://www.abload.de/image.php?img=bf3_2013_01_24_18_50_6ss82.jpg)

1.) Vsync off @ 120HZ : http://www.abload.de/thumb/bf3vsyncoffbhs21.jpg (http://www.abload.de/image.php?img=bf3vsyncoffbhs21.jpg)

2.) Vsync on 120HZ : http://www.abload.de/thumb/bf3vsync120hz4qszp.jpg (http://www.abload.de/image.php?img=bf3vsync120hz4qszp.jpg)

3.) Vsync on 60HZ : http://www.abload.de/thumb/bf3vsync60hz1zikp.jpg (http://www.abload.de/image.php?img=bf3vsync60hz1zikp.jpg)

MFG Junta

Edit : Treiber war der 13.1 WHQL .

Hübie

2013-01-24, 20:24:57

Falls er die Ausschläge bei BF3 mit normalem Vsync & SLI meint:
Gut, optimal ist was anderes. Das Spiel fühlt sich aber auch bei Single-GPU mit Vsync nicht wirklich flüssig an, einfach furchtbar.
Deshalb greif ich dabei mittlerweile lieber gleich zum fps-Limiter.
Ich behalte die Frametimes aber mal mit zukünftigen Treibern im Blick.

Stelle mal prf auf 0 ;D Da erlebst du richtig lustige Sachen in BF3 - kein Witz.

Wie sehen die denn im SLi aus wenn du das mal wieder auf 3 stellst?

@La Junta: what da..:confused: :| Welcher Catalyst&Cap?

La Junta

2013-01-24, 20:30:01

@Hübie :
Cat 13.1 WHQL , kein Cap .

Hier noch die Frametimes für diejenigen die wirklich verstehen was da steht :D

http://uploaded.net/file/0j4c38ze

MFG Junta

Hübie

2013-01-24, 20:40:44

Lade dir mal das aktuellste Cap. Laut AMD gibts da so einige Optimierungen (besonders wegen der frametimes).

pest

2013-01-24, 20:41:21

Danke für die großen Dateien. Mein Argument: "Kein Problem wenn wir bei einem Mausklick alles neuberechnen" zieht hier nichtmehr :D

Die Dateien sind aber rel. unauffällig (Vsynch 60Hz hat allerdings ein Offset von 110%) , das sieht nur komisch aus. Der Framegraph ist wenig aussagekräftig - auch wenn ihr die immer anzeigt.

La Junta

2013-01-24, 20:58:23

@Pest :
Die grossen Dateien kommen von der längeren Spielzeit jeweills :D
Und joa , es ist ohne jegliche ruckler (zumindest keinesfalls auch nur im Ansatz spürbar) .
@Hübie :
WelcheCap ?? das aktuelste ist der 12.11 Cap2 und das sollte schon im 13.1 WHQL schon drin sein denke ich .

MFG Junta

aufkrawall

2013-01-24, 20:58:31

Zeigt mal wieder, dass Single-GPU ohne Limiter/Vsync auch nicht besonders toll laufen muss.

Hübie

2013-01-24, 21:06:16

aufkrawall

2013-01-24, 21:36:29

pest

2013-01-24, 21:41:52

Ich frage mich bei
VSync@120Hz ob du es merkst, dass du >90% der Zeit unter 120fps bleibst
VSync@60Hz ob du es merkst, dass du >50% der Zeit unter 60fps bleibst

Gibt es da kein spürbares Stocken? Ich empfand das immer störend wenn die Framerate unter das VSync Limit rutschte, oder hast du TB an?

La Junta

2013-01-24, 21:52:33

TB war an , also kein stocken .
Ich finde Mouselagg mit Vsync aber extrem störend und zocke deshalb so ziemlich immer mit 120Hz und Vsync off .
Dank 120HZ Monitor hab ich trotzdem kein Tearing (zumindest nicht wirklich sichtbar) .

MFg Junta

aufkrawall

2013-01-24, 21:53:07

Gibt es da kein spürbares Stocken? Ich empfand das immer störend wenn die Framerate unter das VSync Limit rutschte, oder hast du TB an?

TB ist bei dem Spiel immer an.
Stocken/Ruckeln tuts natürlich trotzdem. Schwankende fps sind bei dem Spiel imho ziemlich ekelig.

La Junta

2013-01-24, 21:56:16

TB ist bei dem Spiel immer an.
Stocken/Ruckeln tuts natürlich trotzdem. Schwankende fps sind bei dem Spiel imho ziemlich ekelig.
Find ich irgenwie nicht . Ich empfinde BF3 als recht angenehm was die Reaktion auf schwankende FPS angeht .
Ich merks nur wenn ich unter 60FPS bin . Es fühlt sich schwammig (träge) an , aber keinesfalls ruckelig .

MFG Junta

pest

2013-01-24, 22:02:00

Das ist subjektiv. Das hängt immer vom Frameratenbereich ab

die "hässlichen" Framegraphs sagen halt nicht viel

VSync@60Hz
http://www.abload.de/img/frappo3_02qts7e.png

VSync@120Hz
http://www.abload.de/img/frappo3_01i8s5l.png

obwohl der untere klar breiter streut würde ich ihn bevorzugen

La Junta

2013-01-24, 22:09:54

Und ich zocke wie gesagt mit Vsync off . Trotzdem hast du recht das es ziemlich subjektiv ist .
Edit : Ich werd nächstens mal benchen wenn ich mit Spielsettings zocke . Also nur 2x AA und SSAO off .

Hübie

2013-01-24, 23:16:28

Ich hatte hier doch irgendwo gelesen, dass im 13.1 WHQL das 11.12 CAP2 nicht enthalten sein soll.

Hübie, wegen der Prerendered Frames 0 Sache:
Was passiert denn dann? :D
Nvidia hat die Option ja aus dem Treiber genommen, weil sie zu 1 keinen Unterschied machen soll.

Ach das wusste ich gar nicht. Hab BF3 ewig nicht gespielt. Als ich es auf 0 stellte tauchten häufig Dinge wie Paletten mit Säcken oder gar Spieler plötzlich vor mir auf. Wenn du da noch genug Punkte machst hast du eeeecht skill ;D Ziemlich lustige Sachen erlebt.

aufkrawall

2013-01-29, 19:01:51

Der Geforce 313.96 Treiber fixt adaptives Vsync bei BF3 mit SLI.

sGPU TB Vsync:
http://www.abload.de/thumb/sgputbvsyncajuii.png (http://www.abload.de/image.php?img=sgputbvsyncajuii.png)

2-Way SLI adaptives Vsync:
http://www.abload.de/thumb/mgpuavsynchquqo.png (http://www.abload.de/image.php?img=mgpuavsynchquqo.png)

Subjektiv nicht wirklich ein Unterschied.

aufkrawall

2013-01-29, 23:10:43

Neues Vsync bei Nvidia für SLI (Beta):
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=9635482&postcount=99

Das beseitigt auch die Ruckler in Borderlands 2 mit adaptivem Vsync und Treiber-AA, man kann Framesmoothing damit auslassen
Edit: Framesmoothing sollte weiterhin besser anbleiben, wenn man AA per Custom Bit erzwingt.
http://www.abload.de/thumb/bl2xus2x.png (http://www.abload.de/image.php?img=bl2xus2x.png)

pest

2013-02-25, 07:57:05

Eigentlich ist die neue Version schon lange fertig, aber...

ich möchte AFR-Microruckeln irgendwie quantifizieren

was ich mache ist mir die 1. Differenzen der Framedauern anschauen

meine derzeitige Variante:
es wird die Summe der 1. Differenzen mit verschiedenen Lags berechnet und anschließend das Verhältnis der einzelnen Summen zum Lag-1 berechnet

Ds funktioniert auch ganz gut um das Microrucken quantitativ zu beurteilen
Warum das Verhältnis im Microruckel-Fall i.A. >100% ist weiß ich nicht :confused:

klingt kompliziert, hier ein bisschen code

double FTA::CalcLag(int lag)
{
double energy_lag=0.;;
for (size_t i=lag+1;i<Frames.size();i++)
{
double diffms1=Frames[i].time-Frames[i-1].time;
double diffms2=Frames[i-lag].time-Frames[i-lag-1].time;
energy_lag+=fabs(diffms1-diffms2);
}
return energy_lag;
}

im Hauptprogramm mache ich dann das

double elag1=myFTA.CalcLag(1);
double elag2=myFTA.CalcLag(2);
double elag3=myFTA.CalcLag(3);
double elag4=myFTA.CalcLag(4);
double f1=elag1/elag2;
double f2=elag1/elag3;
double f3=elag1/elag4;

weichen f1,f2 oder f3 stark von 100% ab gibt es einen starken Versatz zwischen 1. und 2., 1. und 3. bzw. 1. und 4. Frame.

Andere Variante: einfach nur nur durchschnittliche Framedauer zu verschiedenen Lags berechnen und das so lassen

Vorschläge?

pest

2013-02-25, 23:04:21

Ich habe einige Funktionen hinzugefügt

Im Framegraph-Tab kann man die Frametimes als Punktwolke anzeigen lassen, einen gleitenden Mittelwert durchlegen und sich das 95%-Interquantil einzeichnen lassen

http://www.abload.de/img/frappo03_00muv4.png

Zusätzlich lässt sich das Wahrscheinlichkeitsmaß zwischen Frames und Zeit ändern

http://www.abload.de/img/frappo03_13muu4.png

Das wird auch direkt im PDF/CDF-Tab umgesetzt

Hier ein CF-Beispiel mit starkem Mikroruckeln

44% der Frames < 30fps, 50% der Frames in [24 fps, 107 fps]
http://www.abload.de/img/frappo03_2qqu3t.png

aber ~75% Zeit < 30 fps, 50% der Zeit in [21 fps, 30 fps]
http://www.abload.de/img/frappo03_33hu64.png

Der Risktab hat eine kleine AFR-Analyse
Je gleichmäßiger die Frameverteilung zwischen den Frames, desto gleichmäßiger sollten die 4 Framezeitdifferenzen sein, in diesem Beispiel haben wir maximales AFR-Ruckeln :freak:

http://www.abload.de/img/frappo03_4p9ugl.png

Emploi

2013-02-26, 00:31:45

Link?

@Startpost?

Spasstiger

2013-02-26, 00:42:39

Interessante neue Features, muss ich mir bei Gelegenheit mal genauer anschauen und mit meinem Analyse-Skript vergleichen. ;)
Hatte ja auch ein Mikroruckelmaß implementiert.

pest

2013-02-26, 05:25:44

Link?

@Startpost?

Erstmal Props :mad:

Interessante neue Features, muss ich mir bei Gelegenheit mal genauer anschauen und mit meinem Analyse-Skript vergleichen. ;)

Das wäre super, habe z.B. einen dämlichen Bug im Quantil-Code gefunden :facepalm:

im Code stand zwar Q(data,0.5)=Median(data), dem war aber nicht so

Butterfly

2013-02-26, 12:41:55

@pest
Schaut gut aus, hier mal was zum testen für dich:

Valley-ExtremHD.zip (http://www.file-upload.net/download-7257561/Valley-ExtremHD.zip.html)
Frametimes & Ergebnis html Datei.

pest

2013-02-26, 19:33:43

lass mich raten, SLI?

raumfahrer

2013-02-26, 19:48:56

Erstmal danke für das Tool.

Zwei Bugs die mir aufgefallen sind:

1) Invalid Floating Point-Meldung beim laden von Daten/wechseln der Reiter/Redraw (also wenn der Graph gezeichnet wird)

2) Der Graph wird nicht richtig gezeichnet, wenn Windows nicht auf 100% Schriftgröße steht

Ich fände einen einstellbaren Wertebereich gut.

Habe Win 7 Pro Sp1 x64 mit (glaube) .NET 3.5.

Butterfly

2013-02-26, 19:52:45

@pest
Nicht ganz, SLI ist der Verbund von nvidia Karten. CrossfireX der Verbund von AMD Karten.
Was sagt Frappo v0.03? Subjektiv läuft es flüssig @ 60Hz:

95,00% Frames in [39,61 fps;132,80 fps]: 93,19 fps

pest

2013-02-26, 20:06:31

1) Invalid Floating Point-Meldung beim laden von Daten/wechseln der Reiter/Redraw (also wenn der Graph gezeichnet wird)

kann ich so nicht nachstellen, kannst du das genauer beschreiben?

2) Der Graph wird nicht richtig gezeichnet, wenn Windows nicht auf 100% Schriftgröße steht

Puh :frown:, das muss, wenn es keine einfache Lösung gibt etwas warten

Ich fände einen einstellbaren Wertebereich gut.

Ordinate und Abszisse?
edit: Du kannst in jedem Graph zoomen!

@pest
Nicht ganz, SLI ist der Verbund von nvidia Karten. CrossfireX der Verbund von AMD Karten.
Was sagt Frappo v0.03? Subjektiv läuft es flüssig @ 60Hz:

schon klar, ich bin zu faul "hast du einen verbund von mehreren Grafikkarten" zu schreiben

naja du verlierst durch das Ruckeln praktisch ~10fps
Ob du das Microruckeln bemerkst, hängt von deinem subjektiven Empfinden und der durchschnittlichen Framerate ab

Ich habe Werte von Blair für Quad-SLI mit deutlich angenehmeren Werten

pest

2013-02-26, 21:22:02

bevor ich noch mehr Mist reinprogrammiere, habe ich mal die aktuelle Version hochgeladen

raumfahrer

2013-02-26, 21:55:47

http://i.imgur.com/L5q8tYL.jpg

Die Messagebox kommt jedes mal, wenn der Graph neu gezeichnet wird. Also beim Einladen einer Datei, beim Klicken auf einen der Reiter oder Redraw.

Der angezeigte Inhalt scheint soweit in Ordnung zu sein.

Habe grad die rechte Maustaste im Plot entdeckt. Im Prinzip sowas nur mit Zahlen. Dass ich also X,Y unten links und X,Y oben rechts angeben kann und mir der entsprechende Ausschnitt geplottet wird.

pest

2013-02-26, 22:05:29

Sehr seltsam...Du scheinst ja der Einzige mit diesem Problem zu sein?!

- kannst du das mal mit Frappo v0.03 testen. Meiner Meinung nach müsste der Fehler dann nur noch kommen wenn du auf den Reiter CDF klickst.

- Ist mit deiner vergrößerten Schrift nur die Ausdehnung der DialogBox falsch oder alles Andere auch?

Habe grad die rechte Maustaste im Plot entdeckt. Im Prinzip sowas nur mit Zahlen. Dass ich also X,Y unten links und X,Y oben rechts angeben kann und mir der entsprechende Ausschnitt geplottet wird.

du kannst auch mit der linken MT zommen. Aber ich baue das noch ein.

Gott ich hasse GUI-Programmierung :>

raumfahrer

2013-02-26, 22:50:06

Der Fehler ist auch in 0.03 noch da. Habe die englische Version von Windows, vielleicht liegt es daran.

Nur die Objekte sind "falsch", die Inhalte scheinen richtig zu sein. Mir kommt es vor, als ob erst die Objekte ans Fenster angepasst werden und anschließend von Windows hochskaliert werden.

http://i.imgur.com/rGpkH6b.jpg

pest

2013-02-26, 23:01:35

Der Fehler ist auch in 0.03 noch da. Habe die englische Version von Windows, vielleicht liegt es daran.

Ja, das ist das Problem. Liegt daran, dass im Deutschen Zahlen als "1,23" eingegeben werden und im Englischen als "1.23". Ich korrigiere das.

Nur die Objekte sind "falsch", die Inhalte scheinen richtig zu sein. Mir kommt es vor, als ob erst die Objekte ans Fenster angepasst werden und anschließend von Windows hochskaliert werden.

Das muss ich mir mal anschauen.

pest

2013-02-26, 23:38:13

Der Fehler ist auch in 0.03 noch da. Habe die englische Version von Windows, vielleicht liegt es daran.

Ist korrgiert und die neue Version ist hochgeladen. Es ist nun egal ob man als Dezimaltrennzeichen einen Punkt oder ein Komma verwendet. Die Standardwerte habe ich allerdings noch nicht geändert.

pest

2013-02-26, 23:42:19

Nur die Objekte sind "falsch", die Inhalte scheinen richtig zu sein. Mir kommt es vor, als ob erst die Objekte ans Fenster angepasst werden und anschließend von Windows hochskaliert werden.

Bitte mal mit Frappo 0.03c testen :)

raumfahrer

2013-02-26, 23:45:10

Super, beide Probleme behoben :up:

pest

2013-02-26, 23:48:18

na das freut mich

man muss meistens nur in den zig eigenschaftsvariablen eine finde die man auf true/false setzen muss.

Emploi

2013-02-27, 02:17:09

Mit was codest du rum?

Saugbär

2013-02-27, 03:24:43

Bitte mal mit Frappo 0.03c testen :)
Frappo meldet immer noch Version v0.03b

pest

2013-02-27, 06:04:23

Mit was codest du rum?

C++ Builder 6 von 2002 :D

Frappo meldet immer noch Version v0.03b

jo, war gestern in Eile und habe vergessen die Nummer in der Dialogbox anzupassen. Vielleicht nenne ich die nächste 0.10 so wird das Projekt nie "fertig" ;)

es sind allerdings noch zig Bugs drinnen (von denen ich weiß), die bis jetzt wohl noch Niemand bemerkt hat :>

Butterfly

2013-02-27, 16:55:10

schon klar, ich bin zu faul "hast du einen verbund von mehreren Grafikkarten" zu schreiben

naja du verlierst durch das Ruckeln praktisch ~10fps
Ob du das Microruckeln bemerkst, hängt von deinem subjektiven Empfinden und der durchschnittlichen Framerate ab

Ich habe Werte von Blair für Quad-SLI mit deutlich angenehmeren Werten
Naja, CF wäre kürzer geweßen. :smile:

Die einzigsten Ruckler die ich deutlich wahrnehmen bei den lauf, sind kurz nach dem Einblenden der Scenen #3, 5 & 11.
Der Rest läuft komplett flüssig, und ich hatte schon GTX580 SLI also von daher weiß ich schon was flüssig bedeutet. :wink:

Das neue v0.03c scheint bisher zu funktioniern, welche nicht erkannte Bugs (easter eggs?) sollen das sein?

MfG

pest

2013-02-27, 17:11:07

Das neue v0.03c scheint bisher zu funktioniern, welche nicht erkannte Bugs (easter eggs?) sollen das sein?

Wie schon geschrieben war ein fetter Bug im Quantil-Code den ich einfach überlesen habe - das hat die Ergebnisse beeinflusst (ab 100 Frames aber irrelevant)

Man muss bedenken, das man n Frames hat, aber nur n-1 Frametimes. Kann sein dass ich irgendwo mit -1/+1 durcheinanderkomme, bzw. meine Modulfunktionen nicht konsequent nutze.

*1) Ein bekannter Bug ist, dass es unter Umständen zu einem Out-Of-Bounds Zugriff im Quantilcode kommt, wenn man das 0.9999.. Quantil berechnet
Eine zusätzliche if-Abfrage ist aber aus Performance-Gründen nicht drin :biggrin:

*2) Das Handling der Chart-Komponenten ist dermaßen übel, dass ich da viele Work-Arounds einbauen muss. Man sieht z.B. das die Ordinate erst woanders gezeichnet wird. Dafür habe ich aber einen Fix der bisher nur im Framegraph-Tab implementiert ist.

Hilfe zu TChart + C++ Builder findet man meist auf russisch ;(

*3) Der Code sieht mittlerweile übel aus :frown:

also keine Logik-Fehler im eigentlichen Sinn :)

pest

2013-02-27, 17:37:15

Ich brauche Design-Vorschläge für so eine Achsen-Skalierungs Box

Spasstiger

2013-02-27, 17:49:30

Das wäre super, habe z.B. einen dämlichen Bug im Quantil-Code gefunden :facepalm:
Kann etwas dauern bis ich dazu komme, mich genauer damit auseinanderzusetzen, bin gerade gut eingespannt mit eigener Arbeit.
Meinen Algo für die "gefühlte Framerate" könntest du trotzdem mal einbauen. ;)

Butterfly

2013-02-27, 20:49:52

Wie schon geschrieben war ein fetter Bug im Quantil-Code den ich einfach überlesen habe - das hat die Ergebnisse beeinflusst (ab 100 Frames aber irrelevant)

Hilfe zu TChart + C++ Builder findet man meist auf russisch ;(

*3) Der Code sieht mittlerweile übel aus :frown:

also keine Logik-Fehler im eigentlichen Sinn :)
Das mit dem Quantil habe ich noch nicht ganz kapiert, was damit gemeint ist.
Jedenfalls scheint es beim CDF Tab Graph einen Unterschied zu geben zwischen läuft sauber und sichtbares Ruckeln.
Je steiler die Kurve desto weniger störende µ-Ruckler:
http://www.abload.de/thumb/frappo_cdf_comparel1u75.jpg (http://www.abload.de/image.php?img=frappo_cdf_comparel1u75.jpg)
links: läuft schlecht & rechts: läuft gut

Mit dem coden an sich hab ich nichts am Hut, daher kann ich jetzt auch kein Logik Bug auf anhieb finden.

Kannst die Hilfe für Tchart + nicht mit Google übersetzen lassen? (ok, die Grammatik ist nicht so gut!)

pest

2013-02-28, 08:09:52

Anschaulich und einfach:

der CDF-Tab ist die kumulierte Verteilungsfunktion (der PDF-Tab)!

Schau dir den PDF-Tab an: rel. Histogramm der Frametimes/FPS!

Sortierst du die nach der Größe und summierst sie auf, ergibt sich die CDF. Die CDF fängt also bei 0 an und strebt gegen 1.

Was kann man damit machen? Mit der CDF kann man Wahrscheinlichkeiten berechnen (als Summe über die PDF).

P(X<x) berechnet dir also die Wahrscheinlichkeit=Anteil an Frames/Zeit das die Frametimes X kleiner als ein vorgegebener Wert x sind.

Das kannst du auch grafisch machen:

Nimm dir eine Frametime z.B. x=30ms, jetzt gehst du auf der x-Achse bei 30ms hoch und schaust bei welchem y-Wert der Graph geschnitten wird=>y=0,6 (für dein linkes Bild).
Das heißt 0,6=60% der Zeit wird unter 30ms verbracht.

*) Ich bin hier was </<= anbelangt bei Frappo nicht ganz konsequent. P(X<x) ist echt kleiner. der CDF-Graph ist aber <=.
Real hat das kaum Auswirkungen (Genauigkeit des Displays) und ich will mich mit FP-Vergleichen (noch) nicht rumschlagen.

Ein Quantil ist ein Unterschreitungsanteil. Er teilt eine (sortierte) Menge in zwei Abschnitte.

das 0,5-Quantil (Median) von [1 2 3 4 5] ist 3, das 0,5-Quantil von [1 2 3 4] muss man approximieren üblicherweise durch (2+3)/2=2,5

Grob gesprochen ist es das Gegenteil vom Berechnen einer Wahrscheinlichkeit.
Für das 0,5-Quantil geht man auf der y-Achse bis zu 0,5 und schaut an welcher Stelle man den Graph schneidet. Ist bei deinem linken Bild also ~26ms.

Du hast richtig festgestellt, dass die Frames gleichmäßiger verteilt sind, je steiler der Graph ist.
Das muss aber nicht bedeuten, dass es wahnehmbar ruckelt. Das hängt nat. davon ab in welchem Frameratenbereich man sich bewegt.

Warum ruckelt das Linke? Schau dir die Ausgabe des 95%-Interquantils an. Das sagt alles.

Butterfly

2013-03-03, 18:23:01

@pest
Danke für die Erklärung! :)

Wer Crossfire nutzt, sollte sich unbediengt das RadeonPro Tool anschauen.
Hier mal ein Vergleich der Frametimes von Crysis 3 (sys@standard):

http://www.abload.de/thumb/radeonprocrysis3frappyms8i.jpg (http://www.abload.de/image.php?img=radeonprocrysis3frappyms8i.jpg)
€dit: Lagged Framediff: [3,65 ms 1,70 ms 3,51 ms 1,84 ms] & [2,23 ms 1,87 ms 2,18 ms 1,93 ms]

Dabei habe ich nur ein Profil angelegt und keine weiteren Änderungen vornehmen müssen. :cool:

pest

2013-03-03, 19:52:55

Gib mal bitte die Lagged-Framediffs an. Nur dort siehst du, ob sich am Mikroruckeln was geändert hat. Bei zwei Karten, reichen die ersten beiden Werte.

Godmode

2013-03-08, 23:39:49

Hab mal die Frametimes in Crysis 3 ermittelt mit 1,2,3 und 4 GPUs.
Als Einstellung verwendete ich 3840x2160 mit 2xSMAA, Ingame alles auf Max.
Vsync hatte ich auf Adaptive und mit Smooth AFR Flag.

CPU: i7-3930k @4.8 GHz
GPU: 4xTitan Max PT, Max TT
Im Treiber HQ-AF geforced.
Win8 x64, Geforce 314.09

pest

2013-03-09, 11:36:40

Hallo, ich habe mir die Sachen mal angeschaut

VarK ist der Variationskoeffizient (über die Frametimes in ms, denke darüber nach es bei der FPS-Einstellung rauszunehmen)

1-GPU: Avg: 18,64 fps, VarK: 15,12%, I-VarK: 7,76%, 90% der Zeit [13,50 fps; 22,61 fps]
2-GPU: Avg: 27,37 fps, VarK: 22,97%, I-VarK: 29,02%, 90% der Zeit [17,53 fps; 33,66 fps]
3-GPU: Avg: 40,84 fps, VarK: 29,74%, I-VarK: 40,09%, 90% der Zeit [21,91 fps; 52,98 fps]
4-GPU: Avg: 50,99 fps, VarK: 45,33%, I-VarK: 55,03%, 90% der Zeit [19,64 fps; 97,25 fps]

Man sieht aber schon an der generellen Schwankung (VarK), dass es ab 3-GPU übel wird.

Hier ein CF-Beispiel (Crysis1) von Ulukay, ich weiß allerdings nicht welche Framelimiter und VSync-Einstellungen verwendet wurden

2x SGSSAA: Avg: 60,91 fps, VarK: 6,59%, I-VarK: 9,79%, 90% der Zeit [59,20 fps; 62,38 fps]
8x SGSSAA: Avg: 42,28 fps, VarK: 44,51%, I-VarK: 45,41%, 90% der Zeit [24,38 fps; 62,20 fps]

Obwohl der Avg-Wert immernoch im spielbaren Bereich liegt, ist es praktisch nicht spielbar.

pest

2013-03-09, 13:31:53

Ich habe nun eine einfache Möglichkeit implementiert die Mikroruckler zu bewerten.

Der Variationskoeffizient gibt ja die generelle Schwankung wieder und die Interframe-Variationskoeffizient die Schwankung zwischen den Bildern.

i.A. unterschieden die Beiden sich nur unwesentlich, es lassen sich aber Beispiele konstruieren wo Letzterer das Spielgefühl besser wiedergibt

Hat man z.b. die Frametimes 10-15-10-15-10 ..., hat man Mikroruckeln und VarK bzw. I-VarK haben einen bestimmten Wert.

Betrachtet man dagegen 10-10-10-15-15-15, hat man eine schnelle Passage und eine Langsame. Die generelle Schwankung ist die Gleiche wie zuvor, die Interframe-Schwankung ist dagegen geringer.

Ich habe die Werte für die obigen Beispiele ergänzt.