[C++] [D3D9] Input Lag - Framelimit - Energiesparplan
Verfasst: 01.10.2017, 14:17
Hallo, ich habe zwei Fragen:
A. Warum reduziert sich bei vielen Spielen der Input Lag, wenn man bei aktivem VSync ein Framelimit etwas unter der eingestellten Hz setzt? Ich habe dieses Phänomen schon mehrmals selbst erlebt und man kann von diesem "Trick" auch oft in Foren lesen. Ich habe aber keine Ahnung, warum das manchmal funktioniert.
B. Zur Erklärung erstmal zwei Bilder:
- Rote Linie = Input Lag (Zeitraum vom Aufbau des Frames inklusive Anzeigen/Present)
- Grüne Linie = Frametimes (protokolliert auf Basis vom Zeitpunkt direkt nach dem IDirect3DDevice9::Present)
- Der Wechsel von Grau zu Weiß zeigt den Punkt, wo die Frametimes optimal wären (16,66 Millisekunden, da 60Hz = 1000 / 60 = 16,66)
1. Windows-Energiesparplan auf Höchstleistung 2. Windows-Energiesparplan auf Ausbalanciert (Standard) Beim zweiten Bild taktet die CPU immer im unteren Bereich hin und her, da die Anforderungen an die CPU auch immer hin und her schwanken. In der Anwendung wird versucht, den Input Lag zu reduzieren, indem man das nächste Frame erst anfängt zu zeichnen, wenn es wirklich nötig ist.
Beispiel ohne den Versuch, den Input Lag zu reduzieren:
a. Benutzereingaben werden verarbeitet
b. Frame wird gerendert und angezeigt
Beispiel mit dem Versuch, den Input Lag zu reduzieren:
a. Benutzereingaben werden verarbeitet
b. Aufgrund des vorigen Frames wird geguckt, wie viel Zeit noch über ist (Zeit bis zum nächsten Present minus Zeit des Zeichnens vom letzten Frame)
c. Ist noch genug Zeit über, geht es mit Punkt a weiter, sonst geht es zu Punkt d
d. Frame wird gerendert und angezeigt
Wie man sieht, macht einem die automatische Takt-Anpassung der CPU da einen gewaltigen Strich durch die Rechnung. Durch den ständig wechselnden Takt ändern sich auch die Renderzeiten, was eine Vorhersage der kommenden Renderzeiten sehr ungenau macht.
Die Frage ist, was mache ich jetzt? Ich sehe zwei Möglichkeiten:
1. Die Funktion zur Reduktion des Input Lags anpassen, damit diese die Taktänderungen erkennt und entsprechend reagiert (riecht nach viel Aufwand)
2. Dafür sorgen, dass die CPU immer mit dem höchsten Takt läuft
Ich tendiere momentan zu 2. Je schneller ein Frame fertig ist, desto geringer ist der Input Lag. Selbst wenn ich es schaffe, die Frametimes bei wechselndem CPU-Takt zu stabilisieren, wird der Input-Lag aufgrund des Takt-Gehopses hin und her schwanken, was eigentlich auch Mist ist.
A. Warum reduziert sich bei vielen Spielen der Input Lag, wenn man bei aktivem VSync ein Framelimit etwas unter der eingestellten Hz setzt? Ich habe dieses Phänomen schon mehrmals selbst erlebt und man kann von diesem "Trick" auch oft in Foren lesen. Ich habe aber keine Ahnung, warum das manchmal funktioniert.
B. Zur Erklärung erstmal zwei Bilder:
- Rote Linie = Input Lag (Zeitraum vom Aufbau des Frames inklusive Anzeigen/Present)
- Grüne Linie = Frametimes (protokolliert auf Basis vom Zeitpunkt direkt nach dem IDirect3DDevice9::Present)
- Der Wechsel von Grau zu Weiß zeigt den Punkt, wo die Frametimes optimal wären (16,66 Millisekunden, da 60Hz = 1000 / 60 = 16,66)
1. Windows-Energiesparplan auf Höchstleistung 2. Windows-Energiesparplan auf Ausbalanciert (Standard) Beim zweiten Bild taktet die CPU immer im unteren Bereich hin und her, da die Anforderungen an die CPU auch immer hin und her schwanken. In der Anwendung wird versucht, den Input Lag zu reduzieren, indem man das nächste Frame erst anfängt zu zeichnen, wenn es wirklich nötig ist.
Beispiel ohne den Versuch, den Input Lag zu reduzieren:
a. Benutzereingaben werden verarbeitet
b. Frame wird gerendert und angezeigt
Beispiel mit dem Versuch, den Input Lag zu reduzieren:
a. Benutzereingaben werden verarbeitet
b. Aufgrund des vorigen Frames wird geguckt, wie viel Zeit noch über ist (Zeit bis zum nächsten Present minus Zeit des Zeichnens vom letzten Frame)
c. Ist noch genug Zeit über, geht es mit Punkt a weiter, sonst geht es zu Punkt d
d. Frame wird gerendert und angezeigt
Wie man sieht, macht einem die automatische Takt-Anpassung der CPU da einen gewaltigen Strich durch die Rechnung. Durch den ständig wechselnden Takt ändern sich auch die Renderzeiten, was eine Vorhersage der kommenden Renderzeiten sehr ungenau macht.
Die Frage ist, was mache ich jetzt? Ich sehe zwei Möglichkeiten:
1. Die Funktion zur Reduktion des Input Lags anpassen, damit diese die Taktänderungen erkennt und entsprechend reagiert (riecht nach viel Aufwand)
2. Dafür sorgen, dass die CPU immer mit dem höchsten Takt läuft
Ich tendiere momentan zu 2. Je schneller ein Frame fertig ist, desto geringer ist der Input Lag. Selbst wenn ich es schaffe, die Frametimes bei wechselndem CPU-Takt zu stabilisieren, wird der Input-Lag aufgrund des Takt-Gehopses hin und her schwanken, was eigentlich auch Mist ist.