FPS lock - AMD Radeon RX Vega 56 8 GB
- Ersteller DimisG
- Erstellt am
Ich greife hier kurz nochmal das Thema auf.
Wenn ich nur Freesync aktiviert habe (vsync und enhanced sync in der AMD Software aus und vsync im Spiel aus, (siehe oben)) und im Spiel werden mir (1440p 75Hz OC (60Hz Monitor)) um die 100 FPS angezeigt, was genau macht jetzt freesync, nichts?
Bei 30 FPS würde es ja versuchen auf 75Hz des Monitors zu syncronisieren (details hab ich mir reingezogen), aber was macht er bei 100 FPS in der beschriebenen Konstellation, "downgraded" der dann auf Monitor Spezifikationen?
Werden beiaktiviertem Freesync immer die originalen FPS angezeigt, also nicht wie bei vsync gedeckelt, wobei ich nicht weis wie das ist wenn zu wenig FPS da sind bei vsync und der Anzeige.
In meinen Thema hier ging es ja generell um höhere FPS als der Monitor als Hz hergibt, wie sieht es den aus, wenn ich auf 40-50 FPS komme, aktiviere ich dann auch nur Freesync wie empfohlen, oder schalte ich z.B. vsync zu?
Danke
Wenn ich nur Freesync aktiviert habe (vsync und enhanced sync in der AMD Software aus und vsync im Spiel aus, (siehe oben)) und im Spiel werden mir (1440p 75Hz OC (60Hz Monitor)) um die 100 FPS angezeigt, was genau macht jetzt freesync, nichts?
Bei 30 FPS würde es ja versuchen auf 75Hz des Monitors zu syncronisieren (details hab ich mir reingezogen), aber was macht er bei 100 FPS in der beschriebenen Konstellation, "downgraded" der dann auf Monitor Spezifikationen?
Werden beiaktiviertem Freesync immer die originalen FPS angezeigt, also nicht wie bei vsync gedeckelt, wobei ich nicht weis wie das ist wenn zu wenig FPS da sind bei vsync und der Anzeige.
In meinen Thema hier ging es ja generell um höhere FPS als der Monitor als Hz hergibt, wie sieht es den aus, wenn ich auf 40-50 FPS komme, aktiviere ich dann auch nur Freesync wie empfohlen, oder schalte ich z.B. vsync zu?
Danke
- Registriert
- Apr. 2008
- Beiträge
- 12.498
Nicht bei einem Monitor mit maximal 75Hz. die LFC(low-framerate-compansation) funktioniert nur wenn die untere Grenze 2,5 mal von der oberen Grenze entfernt ist.
Also z.B. bei 30-120, 30-144 usw. ....da sind z.B. 15FPS kein Problem.
Aber nicht bei 30-75 oder 48-75. Da hast du mit FPS, unter der unteren Grenze, keine Synchronisation.
Und über der oberen Grenze hast du nie synchronisation durch adaptive sync.
Du kannst also entweder damit leben.....einen FPS limiter ein Stück unter der oberen Grenze einsetzen....bei 144Hz z.B. bei 125FPS.....oder du aktivierst V-sync oder enhanced sync.
enhanced sync funktioniert meiner Erfahrung nach besser mit Freesync zusammen als V-sync.
V-sync ist im Grunde double buffer und enhanced sync eine Variante von tripple buffer die auf geringeren input lag eingestellt ist.
Also z.B. bei 30-120, 30-144 usw. ....da sind z.B. 15FPS kein Problem.
Aber nicht bei 30-75 oder 48-75. Da hast du mit FPS, unter der unteren Grenze, keine Synchronisation.
Und über der oberen Grenze hast du nie synchronisation durch adaptive sync.
Du kannst also entweder damit leben.....einen FPS limiter ein Stück unter der oberen Grenze einsetzen....bei 144Hz z.B. bei 125FPS.....oder du aktivierst V-sync oder enhanced sync.
enhanced sync funktioniert meiner Erfahrung nach besser mit Freesync zusammen als V-sync.
V-sync ist im Grunde double buffer und enhanced sync eine Variante von tripple buffer die auf geringeren input lag eingestellt ist.
@Baal Netbeck
hab einen Tag gebraucht um mir etwas wissen anzueignen, aber irgendwie gelingt mir nicht ganz der Durchbruch...
1. vsync verhindert Tearing, indem es höhere FPS auf die "Hz" (Bildwiederholungsrate) des Monitor begrenzt,
bei niedrigere FPS werden Bilder doppel angezeigt (passiert das aber nicht so oder so?), Lag + erhöte Latenz
2. Freesync (adaptive Sync), dynamische Anpassung von höheren FPS an niedrigeren Hz (Monitor), "Bild wird nicht überschrieben", was macht es bei niedrigeren FPS, z.B. 50 FPS dann auch 50 Bilder auf Monitor "50Hz" quasi?
3. Vertikalfrequenz 48 - 75 Hz meines Monitors, ist das mein Freesync Fenster? Ok, 2,5 für LFC erreiche ich nicht,
ich meine ich verstehe langsam, der Bereich ist echt klein
4. Mein aktuelles Spiel laüft auf ca. 120 fps, nur mit Freesync bei 75 Hz Monitor macht es dann ja keinen Sinn,
jetzt verstehe ich auch warum ich Tearing habe, also manuell begrenzen (75 FPS bei mir), oder zusätzlich
enhanced sync an, dann hätte ich Freesync im 48-75 Fenster drunter und drüber wurde enhanced sync
übernehmen und vsync würde ich in der Kostalation außen vor lassen, richtig?
5. Zu Tearing, tritt nur auf wenn höhere FPS auf niedriger Hz treffen? Das Gegenteil verursacht dann ruckeln,
Verzögerungen? Viel benutzen das Wort auch für niedrige FPS auf hohe Hz, das verstehe ich dann nicht.
6. Hab jetzt schon beides gelesen, darum die Frage, was stimmt den wirklich:
enhanced sync ergänzt vsync oder ersetzt vsync...
Ich danke euch/dir!
hab einen Tag gebraucht um mir etwas wissen anzueignen, aber irgendwie gelingt mir nicht ganz der Durchbruch...1. vsync verhindert Tearing, indem es höhere FPS auf die "Hz" (Bildwiederholungsrate) des Monitor begrenzt,
bei niedrigere FPS werden Bilder doppel angezeigt (passiert das aber nicht so oder so?), Lag + erhöte Latenz
2. Freesync (adaptive Sync), dynamische Anpassung von höheren FPS an niedrigeren Hz (Monitor), "Bild wird nicht überschrieben", was macht es bei niedrigeren FPS, z.B. 50 FPS dann auch 50 Bilder auf Monitor "50Hz" quasi?
3. Vertikalfrequenz 48 - 75 Hz meines Monitors, ist das mein Freesync Fenster? Ok, 2,5 für LFC erreiche ich nicht,
ich meine ich verstehe langsam, der Bereich ist echt klein
4. Mein aktuelles Spiel laüft auf ca. 120 fps, nur mit Freesync bei 75 Hz Monitor macht es dann ja keinen Sinn,
jetzt verstehe ich auch warum ich Tearing habe, also manuell begrenzen (75 FPS bei mir), oder zusätzlich
enhanced sync an, dann hätte ich Freesync im 48-75 Fenster drunter und drüber wurde enhanced sync
übernehmen und vsync würde ich in der Kostalation außen vor lassen, richtig?
5. Zu Tearing, tritt nur auf wenn höhere FPS auf niedriger Hz treffen? Das Gegenteil verursacht dann ruckeln,
Verzögerungen? Viel benutzen das Wort auch für niedrige FPS auf hohe Hz, das verstehe ich dann nicht.
6. Hab jetzt schon beides gelesen, darum die Frage, was stimmt den wirklich:
enhanced sync ergänzt vsync oder ersetzt vsync...
Ich danke euch/dir!
- Registriert
- Apr. 2008
- Beiträge
- 12.498
Dann muss ich wohl etwas ausholen.DimisG schrieb:
Ich denke wenn du den Vorgang von deiner Mausbewegung bis zum sichtbaren Kameraschwenk auf dem Monitor verstanden hast, ist der Rest logisch.
Grober Ablauf:
1.Daten der Maus werden von der CPU im Spiel umgesetzt.
2.Der GPU muss mitgeteilt werden, was in der neuen Kameraposition zu sehen ist.(Drawcalls)
3.Die GPU muss die Daten zu einem vollständigen Bild verarbeiten.
4.Der Monitor muss das Bild auslesen und seinen Pixeln die neuen Farbinfos zuweisen.
5.Die Pixel müssen sich umgestellt haben und dein Auge muss es wahrgenommen haben.
Punkt 1 ist hier nicht wichtig.
Punkt 2 ist sehr wichtig für das später Verständnis von möglichen Problemen.
Die GPU muss ja für jedes Bild aufs neue wissen, wo welche Objekte sind, mit welchen Texturen, Effekten, wo Schatten sind usw.
Das alles wird der GPU in "Listen" übergeben....hier gibt es Unterschiede zwischen den DirectX Versionen (vor allem ob DX12, oder ältere)...oder Vulkan/Mantel.....und ob es eine Nvidia oder AMD GPU ist....welche Generation..usw.
Da neuere Spiele immer mehr Objekte, mit immer mehr Polygonen benutzen(die GPUs können ja inzwischen mehr), ist dies in vielen Spielen ein Knackpunkt.
Diese "Drawcalls" lassen sich nicht ganz einfach multithreaden....oft arbeitet ein CPU Kern alle Objekte ab und hat zusätzlich noch andere Aufgaben zu erledigen.
Das führt oft zu einem "CPU Limit", wo die CPU z.B. im Mittel 20ms braucht um die nächste Liste fertig zu stellen, die GPU aber nur 16ms braucht um sie zu einem Bild zu verarbeiten.
So wartet die GPU jedes Mal 4ms auf neue Daten.....es wird nur alle 20ms ein neues Bild fertiggestellt und das Spiel läuft mit 50FPS.
1000/20ms=50 1/s
Wird die CPU z.B. alle 10ms fertig mit den Drawcalls, ist die GPU mit z.B. 16,67ms der limitierende Faktor.
1000/16,67ms=60 1/s
Eine gute Frage ist jetzt, was bei der CPU passiert.....wartet die, bis die GPU sagt: "Ich bin gleich fertig, schick mir schonmal die Liste für den nächsten Frame." .....und dann kausiert sie bis zur nächsten Anfrage?
Oder produziert sie weiter Listen auf Vorrat?
.........Es kommt darauf an.
Spiele habe da wohl einen Spielraum, wie viele Listen auf Vorrat berechnet werden.
Das kann nur die nächste Liste sein..also 1....das kann aber auch 2,3, oder 5 sein.....dann wartet sie mit der Berechnung jedes weiteren Drawcalls immer auf die Ansage der GPU......bei 60FPS also alle 16,67ms.
Extrembeispiel: 5 auf Vorrat.....dann schickt die CPU der GPU auf Anfrage eine neue Liste, aber diese ist gar nicht neu....die Daten entsprechen dem Spielgeschehen von vor 5 Frames....sind also 5x16,67ms= 83ms alt.
Dies führt zu einem größeren Input-Lag.
Ein übliches Problem bei V-sync......aber vor allem dadurch gegeben, wie die Entwickler die Warteschlange definiert haben.
Ob CPU oder GPU limit ....beides hat Vor und Nachteile.
Ein CPU Limit hat keine Warteschlange der Drawcalls.....die GPU reißt der CPU praktisch jede neue Liste ungeduldig aus der Hand und bringt die Infos schnellstmöglich zu einem Bild zusammen.
Aber die Drawcalls können hier sehr ungleichmäßig kommen.
1. Zeigt diese Kameraeinstellung mehr Objekte?
2. Muss auf mehr Daten aus dem Ram gewartet werden (Zugriffszeit L3 Cache z.B. 9ns, aber zum Ram mit mittelmäßiger Geschwindigkeit 75ns)
3. Muss gar auf Daten vom Laufwerk gewartet werden (z.B. SSD 500000ns oder HDD 20000000ns)
4. Belastet etwas anderes den arbeitenden CPU Kern zusätzlich?
5. Die CPU senkt ihren Takt wegen zu heißen Temperaturen in der CPU oder bei der Spannungsversorgung....oder wegen einem Powerlimit usw.
......Alles führt dazu, dass die Drawcalls nicht alle regelmäßig fertig werden.....statt immer 10ms sind welche mit 15ms, 50ms oder 500ms dabei......und das überträgt sich 1 zu 1 auf die GPU, die ihrerseits auch mit Schwankungen zu kämpfen hat....je nachdem wie stark, kann das als Ruckeln wahrgenommen werden.
Ein GPU Limit gibt die Freiheit hier diesen Vorratspuffer zu nutzen.....ist der Puffer wie in dem Beispiel oben 83ms, ist es weniger schlimm, wenn mal ein Drawcall 50ms braucht.....dann gibt es zwar bei dem Inhalt der Frames einen Sprung.....so als würde dein Kameraschwenk für einen Frame zu schnell laufen oder zu langsam laufen, aber die GPU wird nicht aufgehalten, da sie ja eh erstmal Infos auf dem Vorrat verarbeitet.
Setzt das Spiel den Vorrat auf 1, geht dieser Vorteil dahin....dafür wird der Input Lag wieder besser.
Sowohl AMD als auch Nvidia haben inzwischen so einen low latnecy mode, der vom Treiber her versucht den Vorrat auf 1 zu setzten.....so kann man als Spieler entscheiden was man möchte....das was die Spieleentwickler vorgesehen haben oder eben den geringeren Input lag mit den möglichen Problemen von ungleichmäßigerer Bildwiedergabe(Frametimeschwankungen).
Das alles wird der GPU in "Listen" übergeben....hier gibt es Unterschiede zwischen den DirectX Versionen (vor allem ob DX12, oder ältere)...oder Vulkan/Mantel.....und ob es eine Nvidia oder AMD GPU ist....welche Generation..usw.
Da neuere Spiele immer mehr Objekte, mit immer mehr Polygonen benutzen(die GPUs können ja inzwischen mehr), ist dies in vielen Spielen ein Knackpunkt.
Diese "Drawcalls" lassen sich nicht ganz einfach multithreaden....oft arbeitet ein CPU Kern alle Objekte ab und hat zusätzlich noch andere Aufgaben zu erledigen.
Das führt oft zu einem "CPU Limit", wo die CPU z.B. im Mittel 20ms braucht um die nächste Liste fertig zu stellen, die GPU aber nur 16ms braucht um sie zu einem Bild zu verarbeiten.
So wartet die GPU jedes Mal 4ms auf neue Daten.....es wird nur alle 20ms ein neues Bild fertiggestellt und das Spiel läuft mit 50FPS.
1000/20ms=50 1/s
Wird die CPU z.B. alle 10ms fertig mit den Drawcalls, ist die GPU mit z.B. 16,67ms der limitierende Faktor.
1000/16,67ms=60 1/s
Eine gute Frage ist jetzt, was bei der CPU passiert.....wartet die, bis die GPU sagt: "Ich bin gleich fertig, schick mir schonmal die Liste für den nächsten Frame." .....und dann kausiert sie bis zur nächsten Anfrage?
Oder produziert sie weiter Listen auf Vorrat?
.........Es kommt darauf an.
Spiele habe da wohl einen Spielraum, wie viele Listen auf Vorrat berechnet werden.
Das kann nur die nächste Liste sein..also 1....das kann aber auch 2,3, oder 5 sein.....dann wartet sie mit der Berechnung jedes weiteren Drawcalls immer auf die Ansage der GPU......bei 60FPS also alle 16,67ms.
Extrembeispiel: 5 auf Vorrat.....dann schickt die CPU der GPU auf Anfrage eine neue Liste, aber diese ist gar nicht neu....die Daten entsprechen dem Spielgeschehen von vor 5 Frames....sind also 5x16,67ms= 83ms alt.
Dies führt zu einem größeren Input-Lag.
Ein übliches Problem bei V-sync......aber vor allem dadurch gegeben, wie die Entwickler die Warteschlange definiert haben.
Ob CPU oder GPU limit ....beides hat Vor und Nachteile.
Ein CPU Limit hat keine Warteschlange der Drawcalls.....die GPU reißt der CPU praktisch jede neue Liste ungeduldig aus der Hand und bringt die Infos schnellstmöglich zu einem Bild zusammen.
Aber die Drawcalls können hier sehr ungleichmäßig kommen.
1. Zeigt diese Kameraeinstellung mehr Objekte?
2. Muss auf mehr Daten aus dem Ram gewartet werden (Zugriffszeit L3 Cache z.B. 9ns, aber zum Ram mit mittelmäßiger Geschwindigkeit 75ns)
3. Muss gar auf Daten vom Laufwerk gewartet werden (z.B. SSD 500000ns oder HDD 20000000ns)
4. Belastet etwas anderes den arbeitenden CPU Kern zusätzlich?
5. Die CPU senkt ihren Takt wegen zu heißen Temperaturen in der CPU oder bei der Spannungsversorgung....oder wegen einem Powerlimit usw.
......Alles führt dazu, dass die Drawcalls nicht alle regelmäßig fertig werden.....statt immer 10ms sind welche mit 15ms, 50ms oder 500ms dabei......und das überträgt sich 1 zu 1 auf die GPU, die ihrerseits auch mit Schwankungen zu kämpfen hat....je nachdem wie stark, kann das als Ruckeln wahrgenommen werden.
Ein GPU Limit gibt die Freiheit hier diesen Vorratspuffer zu nutzen.....ist der Puffer wie in dem Beispiel oben 83ms, ist es weniger schlimm, wenn mal ein Drawcall 50ms braucht.....dann gibt es zwar bei dem Inhalt der Frames einen Sprung.....so als würde dein Kameraschwenk für einen Frame zu schnell laufen oder zu langsam laufen, aber die GPU wird nicht aufgehalten, da sie ja eh erstmal Infos auf dem Vorrat verarbeitet.
Setzt das Spiel den Vorrat auf 1, geht dieser Vorteil dahin....dafür wird der Input Lag wieder besser.
Sowohl AMD als auch Nvidia haben inzwischen so einen low latnecy mode, der vom Treiber her versucht den Vorrat auf 1 zu setzten.....so kann man als Spieler entscheiden was man möchte....das was die Spieleentwickler vorgesehen haben oder eben den geringeren Input lag mit den möglichen Problemen von ungleichmäßigerer Bildwiedergabe(Frametimeschwankungen).
Hier kann es wie bei den Drawcalls der CPU auch zu einer ungleichmäßigen Bearbeitungsdauer kommen.
Im Grunde auch durch die gleichen Ursachen.
1. Szene komplexer
2. Notwendige Daten sind nicht...oder nicht mehr im VRam.....müssen also aus dem Ram oder gar von einem Laufwerk geholt werden.
3. Es laufen noch andere Lasten wie Videocodierung fürs Streamen/Aufnehmen oder PhysX usw.
4. Die GPU Taktet herunter weil sie in eines ihrer Limits läuft....Spannung, Temperatur, Auslastung, Power....
..............wo es jetzt für das synchronisieren interessant wird:
Die GPU nutzt zwei oder drei Speicher für die Bilder/Frames.
Den Front Buffer, wo ein fertiges Bild drin ist, das bereit ist vom Monitor ausgelesen zu werden.
Und einen Backbuffer, wo nach und nach das neue Bild hineingeschrieben wird.
....normalerweise werden beide umbenannt sobald das Bild fertig im Backbuffer liegt.....Backbuffer wird Frontbuffer und umgekehrt.
Die GPU rendert das neue Bild in den neuen Backbuffer, der vorher Frontbuffer war usw.
Sie kann von dem Monitor gesagt bekommen wenn dieser ein Bild vollständig eingelesen hat....
Bei einem "Adaptive sync"="Freesync"="G-sync compatible" Monitror(und G-sync auch), kann jetzt auch die GPU dem Monitor sagen, dass sie gerade ein Bild fertig hat und die Buffer tauscht.
Im Grunde auch durch die gleichen Ursachen.
1. Szene komplexer
2. Notwendige Daten sind nicht...oder nicht mehr im VRam.....müssen also aus dem Ram oder gar von einem Laufwerk geholt werden.
3. Es laufen noch andere Lasten wie Videocodierung fürs Streamen/Aufnehmen oder PhysX usw.
4. Die GPU Taktet herunter weil sie in eines ihrer Limits läuft....Spannung, Temperatur, Auslastung, Power....
..............wo es jetzt für das synchronisieren interessant wird:
Die GPU nutzt zwei oder drei Speicher für die Bilder/Frames.
Den Front Buffer, wo ein fertiges Bild drin ist, das bereit ist vom Monitor ausgelesen zu werden.
Und einen Backbuffer, wo nach und nach das neue Bild hineingeschrieben wird.
....normalerweise werden beide umbenannt sobald das Bild fertig im Backbuffer liegt.....Backbuffer wird Frontbuffer und umgekehrt.
Die GPU rendert das neue Bild in den neuen Backbuffer, der vorher Frontbuffer war usw.
Sie kann von dem Monitor gesagt bekommen wenn dieser ein Bild vollständig eingelesen hat....
Bei einem "Adaptive sync"="Freesync"="G-sync compatible" Monitror(und G-sync auch), kann jetzt auch die GPU dem Monitor sagen, dass sie gerade ein Bild fertig hat und die Buffer tauscht.
Das ist je nach Monitortechnik auch eine Welt für sich....
Egal ob TN, IPS oder VA .....Ein Hintergrundlicht scheint durch ein farbiges Pixelraster und über Polarisationsfilter und mit Spannung drehbaren Polarisationskristallen wird die Helligkeit aller Subpixel gesteuert.
Die brauchen Zeit um sich auf eine neue Position einzustellen....daher verschwimmen Bewegungen bei einem langsamen Panel......In ihrer Endausrichtung angekommen, halten die Pixel dann diese Position bis zum nächsten Befehl.
Aber es scheint hier Limitierungen zu geben.....erstmal wie schnell sei sich anpassen können.
Bei einem 60Hz Panel hat der Pixel ja 16,6ms zwischen den neuen Befehlen...aber wenn er auch so lange braucht um seine Position zu erreichen, hat er die gerade erst erreicht wen der nächste befehl kommt....Bewegungen verschwimmen.
Es gibt auch viele 144Hz Panel, die zwar alle 6,9ms einen neuen Befehl annehmen, aber je nachdem wie groß der Unterschied ist, es nicht schaffen sich auch in Zeit zu drehen....Dann sehen Farben noch schlechter aus.
Es gibt bei vielen Monitoren einen Overdrive Modus, der die Pixel mit mehr Spannung beschleunigt, sodass sie schneller die drehung machen, aber dafür schießen sie auch eher über das Ziel hinaus......dann ist z.B. in einem Rennspiel das Grad am Rand nicht grün sondern ab und zu gelblich.
Das zweite Problem ist das halten der Position.
Viele der 60Hz Panel sind nicht darauf ausgelegt, wirklich nur alle 33ms einen neuen Befehl zu erhalten und so lange ihre Position zu halten....eingestellte 30FPS sind dann wohl zweimal den gleichen Befehl im Abstand von 16,67ms.....
Bei den Monitoren mit 120+Hz scheint man darauf geachtet zu haben....zumindest können die nicht nur höhere Hz, sondern auf oft bis auf 30 Hz runter funktionieren.
Ein alter Röhrenmonitor regt die Subpixel auf dem Farbgitter mit einem Elektronenstrahl zum leuchten an.....dieser geht auch zeilenweise von oben nach unten, aber die Farben leuchten nur einmal auf, und werden dann dunkler bis zum nächsten refresh.
....Vorteil ist die Reaktionszeit.....Nachteil die oft geringe Auflösung...hoher Stromverbrauch und Platzverbrauch.
Ich warte noch auf gute Gaming OLED Monitore....Das sollte das beste aus beiden Welten verbinden indem die Pixel selbst leuchten.....kein drehen von Kristallen und keine Hintergrundbeleuchtung, die trotz schwarzem Inhalt durchschimmert.....Aber irgendwie scheint das nur für 4K Fernseher entwickelt zu werden.....ein 27" 1440p Monitor mit 240Hz....das wäre mein Traum.....HDR bitte auch.
Egal ob TN, IPS oder VA .....Ein Hintergrundlicht scheint durch ein farbiges Pixelraster und über Polarisationsfilter und mit Spannung drehbaren Polarisationskristallen wird die Helligkeit aller Subpixel gesteuert.
Die brauchen Zeit um sich auf eine neue Position einzustellen....daher verschwimmen Bewegungen bei einem langsamen Panel......In ihrer Endausrichtung angekommen, halten die Pixel dann diese Position bis zum nächsten Befehl.
Aber es scheint hier Limitierungen zu geben.....erstmal wie schnell sei sich anpassen können.
Bei einem 60Hz Panel hat der Pixel ja 16,6ms zwischen den neuen Befehlen...aber wenn er auch so lange braucht um seine Position zu erreichen, hat er die gerade erst erreicht wen der nächste befehl kommt....Bewegungen verschwimmen.
Es gibt auch viele 144Hz Panel, die zwar alle 6,9ms einen neuen Befehl annehmen, aber je nachdem wie groß der Unterschied ist, es nicht schaffen sich auch in Zeit zu drehen....Dann sehen Farben noch schlechter aus.
Es gibt bei vielen Monitoren einen Overdrive Modus, der die Pixel mit mehr Spannung beschleunigt, sodass sie schneller die drehung machen, aber dafür schießen sie auch eher über das Ziel hinaus......dann ist z.B. in einem Rennspiel das Grad am Rand nicht grün sondern ab und zu gelblich.
Das zweite Problem ist das halten der Position.
Viele der 60Hz Panel sind nicht darauf ausgelegt, wirklich nur alle 33ms einen neuen Befehl zu erhalten und so lange ihre Position zu halten....eingestellte 30FPS sind dann wohl zweimal den gleichen Befehl im Abstand von 16,67ms.....
Bei den Monitoren mit 120+Hz scheint man darauf geachtet zu haben....zumindest können die nicht nur höhere Hz, sondern auf oft bis auf 30 Hz runter funktionieren.
Ein alter Röhrenmonitor regt die Subpixel auf dem Farbgitter mit einem Elektronenstrahl zum leuchten an.....dieser geht auch zeilenweise von oben nach unten, aber die Farben leuchten nur einmal auf, und werden dann dunkler bis zum nächsten refresh.
....Vorteil ist die Reaktionszeit.....Nachteil die oft geringe Auflösung...hoher Stromverbrauch und Platzverbrauch.
Ich warte noch auf gute Gaming OLED Monitore....Das sollte das beste aus beiden Welten verbinden indem die Pixel selbst leuchten.....kein drehen von Kristallen und keine Hintergrundbeleuchtung, die trotz schwarzem Inhalt durchschimmert.....Aber irgendwie scheint das nur für 4K Fernseher entwickelt zu werden.....ein 27" 1440p Monitor mit 240Hz....das wäre mein Traum.....HDR bitte auch.
5.Die Pixel müssen sich umgestellt haben und dein Auge muss es wahrgenommen haben.
Hier wird es nochmal kompliziert....und schwierig von der Datenlage.
Das Auge kann Farben und Helligkeit unterschiedlich wahrnehmen....das Gehirn scheint die Daten auch hirgendwie getaktet wahrzunehmen, wie man z.B. sehen kann, wenn man aus dem Auto die Felgen einem anfahrenden Autos neben einem beobachtet(bitte nur als Beifahrer).
Dann sieht man die Speichen schneller werden, aber irgendwann sieht es so aus als würden sie rückwärts laufen.
Das spricht für eine bestimmte Taktung der Wahrnehmung, weil die Speiche 2 sich so schnell bewegt, dass sie bei der nächsten Taktung eher bei der Position von Speiche 1 angekommen ist.....Das Gehirn ordnet dann Speiche 2 zu Speiche 1 zu....und nimmt an, dass sich Speiche 1 langsam rückwärts bewegt hat.
Auf der andere Seite können wir Zwischenbilder in Filmen wahrnehmen die bei dieser Taktung nicht zu sehen sein sollten....und wir geben uns bei PC Spielen, nicht mit den 24 FPS aus dem Kino zufrieden.
....die 24FPS aus dem Kino sind nur deshalb nicht ruckelig, weil sie auch langsam aufgenommen wurden bzw. am Computer Motion Blur eingefügt wurde.
Das Gehirn stört sich nicht an den 24 FPS, weil alles in schneller Bewegung entweder durch die Belichtungszeit der Aufnahme oder absichtlich unscharf gemacht wurde.
Für PC Spiele ist Motion Blur eine zusätzliche Arbeit....und bezieht vorherige Frame mit ein...alles nicht so einfach und daher stört sich das Gehirn an 24FPS, weil es die Sprünge genau sehen kann.
Hier ist TFT noch ein weiterer Nachteil, da das Auge sich wohl zusätzlich an den Standbildern stört.
Sich bewegende Objekte werden ja von Monitor Refresh zu Refresh ein Stück weiter gesetzt, aber da bleiben sie dann ja stehen......das Auge sieht also "Sprung", "Stillstand", "Sprung","Stillstand" ....
Das Auge ist verwirrt und auch wenn es das nicht unbedingt als Ruckeln wahrnimmt, so fällt es schwer, sich bewegende Objekte, an Monitor scharf zu sehen.....zusätzlich zu den Problemen der Pixel, sich schnell anzupassen.
....Ein Röhrenmonitor ist da deutlich angenehmer, da er die Position nur kurz aufflackern lässt.
Also "Sprung","Schwarz", "Sprung", "Schwarz".....
Das macht angenehmere Bewegungen für das Gehirn.....es gibt auch TFT Monitore, die das Hintergrundlicht flackern lassen, damit es eher so wahrgenommen wird wie am Röhrenmonitor.
Was wir auf jeden Fall auch sehen ist Tearing
Das Auge kann Farben und Helligkeit unterschiedlich wahrnehmen....das Gehirn scheint die Daten auch hirgendwie getaktet wahrzunehmen, wie man z.B. sehen kann, wenn man aus dem Auto die Felgen einem anfahrenden Autos neben einem beobachtet(bitte nur als Beifahrer).
Dann sieht man die Speichen schneller werden, aber irgendwann sieht es so aus als würden sie rückwärts laufen.
Das spricht für eine bestimmte Taktung der Wahrnehmung, weil die Speiche 2 sich so schnell bewegt, dass sie bei der nächsten Taktung eher bei der Position von Speiche 1 angekommen ist.....Das Gehirn ordnet dann Speiche 2 zu Speiche 1 zu....und nimmt an, dass sich Speiche 1 langsam rückwärts bewegt hat.
Auf der andere Seite können wir Zwischenbilder in Filmen wahrnehmen die bei dieser Taktung nicht zu sehen sein sollten....und wir geben uns bei PC Spielen, nicht mit den 24 FPS aus dem Kino zufrieden.
....die 24FPS aus dem Kino sind nur deshalb nicht ruckelig, weil sie auch langsam aufgenommen wurden bzw. am Computer Motion Blur eingefügt wurde.
Das Gehirn stört sich nicht an den 24 FPS, weil alles in schneller Bewegung entweder durch die Belichtungszeit der Aufnahme oder absichtlich unscharf gemacht wurde.
Für PC Spiele ist Motion Blur eine zusätzliche Arbeit....und bezieht vorherige Frame mit ein...alles nicht so einfach und daher stört sich das Gehirn an 24FPS, weil es die Sprünge genau sehen kann.
Hier ist TFT noch ein weiterer Nachteil, da das Auge sich wohl zusätzlich an den Standbildern stört.
Sich bewegende Objekte werden ja von Monitor Refresh zu Refresh ein Stück weiter gesetzt, aber da bleiben sie dann ja stehen......das Auge sieht also "Sprung", "Stillstand", "Sprung","Stillstand" ....
Das Auge ist verwirrt und auch wenn es das nicht unbedingt als Ruckeln wahrnimmt, so fällt es schwer, sich bewegende Objekte, an Monitor scharf zu sehen.....zusätzlich zu den Problemen der Pixel, sich schnell anzupassen.
....Ein Röhrenmonitor ist da deutlich angenehmer, da er die Position nur kurz aufflackern lässt.
Also "Sprung","Schwarz", "Sprung", "Schwarz".....
Das macht angenehmere Bewegungen für das Gehirn.....es gibt auch TFT Monitore, die das Hintergrundlicht flackern lassen, damit es eher so wahrgenommen wird wie am Röhrenmonitor.
Was wir auf jeden Fall auch sehen ist Tearing
Tearing
Tearing entsteht, wenn der Monitor gerade dabei ist das Bild aus den Frontbuffer auszulesen und damit seine Pixel zu füttern.....und währenddessen die GPU mit ihrem aktuellen Bild fertig wurde und die Buffer tauscht....das Auslesen erfolgt zeilenweise und mit dem Umbenennen springt der pointer auf den anderen Buffer.
Sagen wir der Monitor hatte schon die Hälfe des Frames ausgelesen, als der Tausch erfolgt...dann ist die obere Hälfte des Monitorbildes der ältere Frame und die untere Hälfte der neue Frame.
Bei einem seitlichen Kameraschwenk wird das Bild also zerrissen und obere und untere Hälfte des Bildes sind seitlich verschoben.
Scrollt man z.B. nach oben oder unten auf einer Karte, schieben sich die Bilder ineinander oder Teile sind doppelt zu sehen.
Am schlimmsten ist dies, wenn FPS und Hz ungefär gleich sind.....dann bleibt diese Grenze von neuem zu altem Bild auf der gleichen Position am Monitor.
z.B. erster Monitor refresh.... obere Hälfte Frame1, untere Frame2 ...nächster Refresh, obere Hälfte Frame2, unter Hälfte Frame3 usw.
Weichen FPS und Hz weiter ab(und sind nicht wieder vielfache voneinander), springt die Grenze von refresh zu Refresh an immer neue Stellen....das ist für das Auge weniger wahrnehmbar.
Auch hat ein 144Hz Monitor hier unabhängig von den FPS deutliche Vorteile.
Bei 60Hz, ist das Tearing ja volle 16,67ms lang zu sehen und bei einem Kameraschwenk ist auch der Versatz an der Stelle des Tearings soweit, wie die Kamera sich in 16,67ms bewegt hat.
Und bei um die 60 FPS hat auch praktisch jeder Refresh Tearing.
Bei einem 144Hz Monitor ist das Tearing nur 6,9ms lang zu sehen.....
Und bei wieder grob 60 FPS folgt auf ein Bild mit Tearing, 6,9ms später ein Bild, bei dem der obere Teil des alten Bildes durch das neue ersetzt wird....und damit mit dem unteren Teil übereinstimmt.....also kein Tearing.
So sind also nicht alle Bilder mit Tearing und das tearing ist kürzer zu sehen.
Mit FPS um die 144, hat der 144Hz Monitor zwar auf jedem Bild Tearing, aber eben nur für 6,9ms, und nur soweit wie die Kamera in 6,9ms gewandert ist.
Der 60 Hz Monitor hat auf jedem Bild 2 bis 3 mal Tearing, wenn jeder Versatzt auch nur so groß ist, wie die Kamera in 6,9ms gewandert ist.......allerdings hat man dann auch wieder 16,67ms lang Zeit das Tearing zu bemerken.
Synchronisieren
Also irgendwie muss man den Monitor mit dem Wechsel der Buffer synchronisieren.
A Entweder man lässt die GPU auf den Monitor warten,
B Oder die GPU schreibt dem Monitor vor, wann er den Refresh zu starten hat.
Zu A gibt es verschiedene Techniken.....V-sync oder fast sync(Nvidia)=enhanced sync(AMD), ......und Exoten.DimisG schrieb:
Damit die GPU auf den Monitorrefresh warten kann, muss sie zwangsläufig schneller fertig sein als ein refresh cycle.
Braucht der 60Hz Monitor 16,67ms, und die GPU im Schnitt 10ms, ist alles in Ordnung.
Dann stellt sie ihren Frame fertig, wartet noch etwas, bis der Monitor Bereitschaft signalisiert...dann wechselt sie die Buffer und rendert den nächsten Frame.
Aber wenn sie verspätet von der CPU die Daten bekommt weil die Drawcalls zu lange gedauert haben, oder weil sie für diesen Frame doch länger als 16,67ms gebraucht hat, gibt es ein Problem.
Entweder wird die Synchronisation jetzt ausgesetzt oder auf "30Hz" gezwungen.
Da bin ich mir nicht sicher wer das entscheidet....ich nehme an der Spieleentwickler....
Um Tearing zu vermeiden kann jetzt nochmal das gleiche Bild dargestellt werden.
Etwas blöd, wenn die GPU nur knapp zu langsam war.....17ms gebraucht hat und jetzt für 33,3ms das gleiche Bild zu sehen ist.
Danach ist das Bild zu sehen, das den geplanten Inhalt von vor 16,23ms zeigt....also irgendwie Inhaltlich zu spät kommt....einige Frames später(je nach "Vorratshaltung" der Drawcalls) gibt es dann einen Sprung im Inhalt, weil die CPU statt der üblichen 16,67ms auch einmal eine 33,3ms Pause machen muss um wieder passend zur GPU zu laufen.
........Alternativ...und ich glaube das wird meistens gemacht, wird V-sync einfach kurz ignoriert....die GPU ist nicht rechzeitig fertig geworde, aber sie tauscht einfach die Buffer ohne auf den Monitor zu achten....dann hat der eine Monitorrefresh zwar Tearing, aber sie kann sich ja für den nächsten refresh wieder an V-sync halten.....und das ohne die anderen Probleme.
Wenn die GPU also nicht zuverlässig jeden Frame auch in unter 16,67ms liefern kann, hat man entweder doch Tearing, oder jede Menge Probleme mit Stottern und ungleichmäßig ablaufenden Bewegungen.
Und wenn die Frames immer schnell genug kommen, dann werden sie durch den Monitor eingebremst(es passiert das gleiche wie ich oben beim GPU limit beschrieben habe).....das kann Strom sparen, aber auch zu mehr Input Lag führen....wie ich oben beschrieben habe sammeln sich dann ja Drawcalls an....mal mehr mal weniger ...und um so mehr, um so zuverlässiger wird auch die GPU rechtzeitig versorgt....nur eben mit veralteten Infos.....das ist dann zwar flüssig, aber das Geschehen kommt nicht so schnell auf den Schirm wie es könnte.
fast sync und enhanced sync sind tripple Buffer varianten.
Da wird von der GPU noch ein weiterer Backbuffer verwendet.
Situation.....Monitor liest gerade den Fronbuffer aus.....die GPU wird fertig mit ihrem Bild im backbuffer 1.....dann stoppt sie nicht und wartet auf den Monitor, sondern macht gleich weiter mit dem rendern des nächsten Bildes in Backbuffer 2.
ist sie schneller fertig mit dem Rendern in Backbuffer 2, als der Monitor gebraucht hat, dann wird Backbuffer 1 verworfen und der Monitor bekommt Backbuffer 2 als neuen Frontbuffer.....der Monitor überspringt also ein Frame um das aktuellste Bild auf das Display zu bringen.
Und ist die GPU noch nicht mit dem Frame in Backbuffer 2 fertig, stellt der Monitor das Bild aus Backbuffer1 dar....und dann entweder im nächsten refresh das Bild von Backbuffer 2 oder schon das übernächste Bild.
Das hat zwei Vorteile....die GPU kann auch mal etwas über 16,67ms brauchen, solange sie davor entsprechend schneller gewesen ist....dann kann sie sich zumindest kleine Schwankungen erlauben und wenn sie sehr viele FPS schafft, sinkt auch der Input lag.
Denn jetzt ist sie nicht mehr auf die 16,67ms des Monitors begrenzt.....das Beispiel von oben mit den fünf, auf Vorrat, erstellten Drawcalls, hatte mit V-sync 60Hz, 5x16,67=83ms gebraucht......
Schaffen CPU und GPU jetzt mit enhanced sync, 200FPS im GPU limit, sind 5 Drawcalls nur noch 25ms.....und im CPU limit verschwindet der Vorrat und es sind nur 5ms.
Es gibt auch noch weitere Varianten von tripple Buffer....man kann anstelle des Ansatzes, der den Input-Lag reduziert, auch auf eine sicherere Einhaltung von V-sync setzen....hier wird der zweite Buffer nicht genutzt, um möglicherweise einen Frames zu überspringen, sondern um einen Puffer aufzubauen.....die GPU rechnet also wann immer möglich einen Frame auf Vorrat und bietet dem Monitor nur den älteren an....so kann sie ab und zu, einen ganzen refresh länger brauchen und trotzdem war immer alles synchronisiert.
....allerdings bremst sei dann nach dem Puffer auch wieder....und dann sammeln sich Drawcalls und noch ein Bild im Backbuffer an....schlechtester input-lag inclusive.
Adaptive sync=freesync=G-sync compatible
Hier soll der Monitor sich der GPU Ausgabe anpassen.
CPU und GPU arbeiten einfach so wie sie es tun würden ohne sich um die synchronisation zu kümmern, aber die GPU sagt dem Monitor Bescheid, wenn er ein neues Bild einlesen kann.
Wie oben beschrieben, ist der Monitor dabei nicht völlig flexibel.
Er ist eingeschränkt darin wie schnell er einen refresh durchführen kann und auch wie lange seine Pixel das Bild halten können.
Nehmen wir mal Monitore mit 48-75Hz.
Kommen die Bilder von der GPU im Abstand von 12ms.....aber der Monitor schafft minimal alle 1000/75=13,33ms einen refresh, dann kann er das erste Bild darstellen, aber wenn das zweite nach 12ms(83FPS)
fertig ist, ist er noch nicht mit dem refresh des ersten fertig.....die Buffer wechseln und es gibt Tearing.
Auch wenn das System Probleme hat und nur 40FPS schafft, funktioniert es nicht.
Die GPU hat erst nach 25ms(40FPS) einen Frame fertig....der Monitor kann seine Pixel aber nur für 20,8ms halten.
Also wird er nach 20,8ms einfach nochmal das gleiche Bild aus dem Frontbuffer auslesen und darstellen....aber 4,2ms später wechselt die GPU die Buffer und die Darstellung hat wieder Tearing.
Es müssen also jedes Frametime immer im Bereich von 13,3 bis 20,8ms liegen.....selbst wenn der Durchschnitt der FPS zwischen 48 und 75FPS liegt, so schwanken die einzelnen Frametimes doch in der Regel deutlich hoch und runter.....es wir immer wieder dazu komme, dass die Frametimes nicht zur range des Monitors passen und es doch wieder Tearing gibt.
30-144Hz ....das ist schon deutlich brauchbarer.
144FPS überschreitet man nicht so einfach......und unter 30 fällt man zwar ab und zu, aber hier kann LFC greifen.
Die Low Framerate Compansation ermöglicht es trotz niedrigen FPS noch zu synchronisieren.
Braucht ein Frametime 50ms(20FPS), kann der Monitor das Bild mehrfach darstellen.
Er kann ja 6,9ms schaffen und 33ms halten......ich bin mir nicht sicher, wie es intern geregelt ist, aber mehrere Varianten sind möglich....Das er so schnell wie möglich den Refresh macht, und dann nach 6,9ms sofort den nächsten startet....oder dass er 33,3ms wartet...dann den refresh des gleichen Bildes macht und wenn nach 50ms das neue Bild kommt ist er bereit dieses sofort darzustellen.
Aber wie genau...keine Ahnung....funktioniert aber scheinbar.....und auch wenn theoretisch sowas wie 48-100 funktionieren könnte.....2x47 wären in der Range....2x40.....3x20...usw, scheint es da einen Sicherheitsspielraum geben zu müssen.
....Ich hoffe deine Fragen haben sich in meinem Roman geklärt....andernfalls nochmal in kurz
Ja...innerhalb der Monitorrange sind 50 FPS auch 50Hz am Monitor.DimisG schrieb:
Ja das ist deine range....das Fenster in dem Freesync funktioniert......und ja es ist echt klein.DimisG schrieb:
Auf 75FPS mit einem Framelimiter begrenzen wird nicht funktionieren....so genau arbeitet der nicht, und es werden grob die Hälfte der Frames schneller als 13,33ms sein und damit Tearing haben.DimisG schrieb:
So 65 könnte man als sichere Variante versuchen....mit AMD Karte ist Radeon Chill auch eine Möglichkeit, das ist aber auch extrem knapp......könnte man auf 52-70 setzen...dann alndet man mit Bewegung vermutlich grob bei 65FPS.
enhanced sync übernimmt dann für alles über 75FPS, aber der Übergang zwischen den beiden Techniken kann je nach Spiel wohl Probleme machen.....dann stockt es beim Übergang und dann hat man doch lieber Tearing.
Da wird gerne Vieles durcheinander geworfen.DimisG schrieb:
Ich bin da auch selbst öfter flapsig.
Aber was du da beschreibst ergibt für mich keinen Sinn...Ohne synchronisieren hat man immer Tearing.....und niedrige FPS oder noch schlimmer, hohe Frametimepeaks machen dann das Ruckeln......aber das sind zwei verschiedene Dinge.......die sich zwar gegenseitig beeinflussen, denn wenn die GPU bei einem Ruckler zu lange braucht und daher V-sync oder die Freesync Range nicht reicht, gibt es den Ruckler und zusätzlich noch Tearing.
....Puh.DimisG schrieb:
Also enhanced sync setze ich ja im Treiber......aber wenn ich jetzt zusätzlich im Spiel V-sync aktiviere, dann weiß ich nicht, was da Priorität hat.
Beides kann nicht laufen....das eine nutzt zwei Buffer, das andere drei....aber welches genutzt wird, da bin ich überfragt.....ich mache V-sync in Spielen immer aus, und nutze Freesync.....und wenn die FPS über 144 gehen, dann habe ich zwar Tearing, aber eher so ein leichtes "franseln"....das stört mich meist nicht.
enhanced sync hatte ich auch mal probiert und bei mir lief es eigentlich gut...aber da ich auch öfter Benchmarks mache, wollte ich nichts aktiv haben, was potentiell die FPS beeinflussen könnte.
Zuletzt bearbeitet:
Erstmal MEGA Dank für die extrem ausführliche Antwort und deine Zeit , hab jetzt natürlich paar Tage zur Aufarbeitung gebraucht 😅.....
Mir ist in der Tat sehr vieles klar geworden, aber bisschen muss noch nachjustiert werden.
2. Liefert meine GPU ein Frame alle 25ms und das die ganze Zeit (40FPS und somit außerhalb des Freesync Bereichs), dann gibt es definitiv Probleme richtig? Vsync würde das Bild wiederholen bis ein neues da ist, oder durch die GPU übergangen werden und man hätte Tearing. Was passiert dann bei Enhanced sync? beide Buffer können in der Zeit nicht bedient werden, gleiches Bild? oder auch hier übergehen von Enhanced sync und Tearing
sprich es ist keine alternative unter 48FPS (untere Ebene Freesync) zu fallen, korrekt?
3. hab mit Chill die FPS Range begrenzt wie empfohlen musste aber dafür Anti-Lag deaktivieren und ich meine das lief deutlich schlechter ohne Anti-Lag oder mit Chill weißt jetzt nicht was stört, gerade die Videosequenzen im Spiel haben deutlich gehackt, eine Erklärung?
4. Es gibt ja im Spiel den max Begrenzer an FPS, früher gab es noch FRTC im Treiber jetzt wohl nicht mehr, neben Chill andere alternativen?
Danke, danke und danke nochmal.
, hab jetzt natürlich paar Tage zur Aufarbeitung gebraucht 😅.....Mir ist in der Tat sehr vieles klar geworden, aber bisschen muss noch nachjustiert werden
.1. Das verstehe ich nicht ganz, die CPU kann alle 10ms liefern und die GPU alle 16,67ms verarbeiten und 5 Listen auf Vorrat im Beispiel hier. Warum schickt die CPU jetzt eine Liste auf Anfrage die 5 Frames alt ist, da hab ich noch einen Denkfehler.Baal Netbeck schrieb:
2. Liefert meine GPU ein Frame alle 25ms und das die ganze Zeit (40FPS und somit außerhalb des Freesync Bereichs), dann gibt es definitiv Probleme richtig? Vsync würde das Bild wiederholen bis ein neues da ist, oder durch die GPU übergangen werden und man hätte Tearing. Was passiert dann bei Enhanced sync? beide Buffer können in der Zeit nicht bedient werden, gleiches Bild? oder auch hier übergehen von Enhanced sync und Tearing
sprich es ist keine alternative unter 48FPS (untere Ebene Freesync) zu fallen, korrekt?
3. hab mit Chill die FPS Range begrenzt wie empfohlen musste aber dafür Anti-Lag deaktivieren und ich meine das lief deutlich schlechter ohne Anti-Lag oder mit Chill weißt jetzt nicht was stört, gerade die Videosequenzen im Spiel haben deutlich gehackt, eine Erklärung?
4. Es gibt ja im Spiel den max Begrenzer an FPS, früher gab es noch FRTC im Treiber jetzt wohl nicht mehr, neben Chill andere alternativen?
Danke, danke und danke nochmal.
Ähnliche Themen
