News GeForce 551.46 Hotfix: Nvidia-Grafiktreiber behebt Mikroruckler und Stottern

Mimir schrieb:
Wie oft denn noch?
https://blurbusters.com/gsync/gsync101-input-lag-tests-and-settings/15/


Wait, why should I enable V-SYNC with G-SYNC again? And why am I still seeing tearing with G-SYNC enabled and V-SYNC disabled? Isn’t G-SYNC suppose to fix that?



I still don’t get it, then why do I need an FPS limit with G-SYNC, and why does the limit have to be below the refresh rate? Why not “at” it?



Alright, I now understand why the V-SYNC option and a framerate limiter is recommended with G-SYNC enabled, but why use both?






Ein FPS limiter kann kein Tearing verhindern, weil er nicht an den Scanout des Displays gekoppelt ist. Es reicht jede noch so kleine Unregelmäßigkeit, eine simple Änderung der Framerate bzw. Frametime und schon übersteuerst du die Bildwechselzeit deines Displays, bist dadurch ausserhalb der Gsync Range und bekommst tearing. Ein Limiter ist kein Ersatz für den Sync. Und nochmal, gsync greift für diese Frames nicht.

Gsync macht das was es soll, der limiter macht das was er soll und vsync macht das was es soll.
Dass leute glauben, man kann irgendwas davon weglassen liegt einfach im fehlenden Detailverständnis der Leute. Hier eben, dass man glaubt, mit einem FPS limiter sein kein Sync mehr notwendig, weil die Frametimes in der Gsync range bleiben würde. Genau das ist aber nicht der Fall.
Du könntest in der praxis auf Vsync verzichten, wenn du den FPS limiter sehr niedrig ansetzt. Meinetwegen 100 FPS limit bei einem 144 Hz Display. Nur stell ich dann die Frage, was man sich davon erhofft. Vsync erzeugt mit der Config Gsync + Vsync + FPS Limiter eh keinen Inputlag und erlaubt es dir, die Framerate nahe der maximalfrequenz zu halten und dabei tearing zu vermeiden.


Daher frag ich mich auch, wozu die Diskussion, dass man gerne Vsync off nutzen würde.
Scheinbar gibts hier zwei Punkte, die nicht verstanden wurden.

Zum einen scheint nicht verstanden worden zu sein, warum man bei Gsync + FPS Limit zusätzlich Vsync braucht.
Zum anderen scheint auch nicht verstanden zu sein, warum Gsync + Vsync + FPS Limit keinen Vsync lag erzeugen kann.
Ja, eignetlich müsste sich CB dem Thema mal annehmen und es aufbereiten.
Ergänzung ()

Kartoffel! schrieb:
Nach längerem Testen kann ich sagen das es viel besser mit VSync geworden ist, aber nicht zu 100% behoben.

Sobald ich HAGS in Windows wieder aktiviere kommt es z.b. bei FH 5 nach 2-3 Schnellreisen immer noch zu Stuttering wenn die Kamera hinter das Auto schwenkt.

Das gute ist, dass es dann nicht mehr dauerhaft so bleibt, sondern nur während dem Kameraschwenk.
Ja, HAGS scheint mir immer noch sehr unbrauchbar.
 
  • Gefällt mir
Reaktionen: -MajorP- und amorosa
Nolag schrieb:
Ich glaube deine Behauptung basiert auf dem Irrtum, dass die Frametime auch die Scanout-Zeit ist.
Nein. Das meine ich nicht.

Nolag schrieb:
Der Scanout passiert immer mit der Maximalfrequenz
Ja, so ist es. Ein 144 Hz Monitor, selbst wenn er während des adaptive syncing grade auf 76 Hz geschaltet ist, hat immer noch eine fixe Scanoutzeit von 6,94 ms (sofern in den Anzeigeeinstellungen des Treibers 144 Hz ausgewählt wurde).

Das ist aber nicht das, was ich versucht habe zu beschreiben.

Nolag schrieb:
weshalb man VSync nicht benötigt, wenn man einen Limiter unterhalb der Maximalfrequenz setzt. Ein Überschreiben des Puffers während des Scanout ist dann unmöglich.
Eben nicht. Die Scanouttime bezieht sich auf die Zeit, die von der ersten Zeile und Spalte des Pixelrasters bis hin zur letzten Zeile und Spalte benötigt wird. Diese Zeit bleibt konstant, egal auf welcher Refreshrate der Moni gerade läuft. Die Refreshrate kontrolliert lediglich, wie OFT der Scanout pro Sekunde stattfindet. Siehe Beispiel mit 100 fps @ 200 Hz, wo jedes Bild zwei mal gezeichnet wird.

Das alles hat aber zunächst nichts mit dem Zeitpunkt des Bildwechsels zu tun. Mit V-Sync, egal ob alleine oder parallel zu adaptive sync, erfolgt der Bildwechsel immer so, dass ein neues Bild immer in obersten Zeile und ersten Spalte des Monitors-Pixelmatrix begonnen wird.

Nolag schrieb:
Blur Busters erklärt genau, warum in der Sync Range kein VSync nötig ist. Dein 100 fps Beispiel ergibt daher keinen Sinn.
Blur Busters erklärt genau, warum es dennoch zu Tearing kommt.
Adaptive Sync berechnet in Abhängigkeit von den aktuellen Frametimes die benötigte Zeitspanne zwischen zwei Bildwechsel und beeinflusst so die Refreshrate, d.h. wie OFT der Scanout stattfinden soll. Hätten Frametimes 0,0% Varianzen, wäre die Verarbeitungszeit 0,0 ms und der Framelimiter zu 100,0% genau, würde hier der Bildwechsel tatsächlich beim allerersten Pixel oben links beginnen. Das ist aber nicht der Fall! Weil es permanent Frametimevarianzen gibt.

Frametime Spikes sind eine abrupte Unterbrechung der vom System ausgegebenen Frames und treten bei einem fähigen Setup mit einer effizienten Spiel-Engine typischerweise aufgrund von Ladebildschirmen, Shader-Kompilierung, Streaming von Hintergrund-Assets, automatischen Speicherungen, Netzwerkaktivitäten und/oder der Auslösung eines Skripts oder Physiksystems auf, kann aber auch durch ein unfähiges Setup, eine ineffiziente Spiel-Engine, einen schlechten Netcode, zu wenig RAM/VRAM und eine Überbelegung von Auslagerungsdateien, falsch konfigurierte SLI-Setups (oder eingeschränkte Spielunterstützung), fehlerhafte Treiber, bestimmte oder übermäßige Hintergrundprozesse, Konflikte mit Overlays oder Eingabegeräten im Spiel oder eine Kombination aus all dem verschlimmert werden.

Nicht zu verwechseln mit anderen Leistungsproblemen, wie Framerate-Verlangsamung oder V-SYNC-induziertem Stottern, manifestieren sich Frametime-Spikes als gelegentliche Ruckler oder Pausen und dauern in der Regel nur Mikro- bis Millisekunden (im schlimmsten Fall Sekunden), wobei die Framerate bis in den einstelligen Bereich absinkt und die Frametime gleichzeitig auf über 1000 ms ansteigt, bevor sie sich wieder normalisiert.

G-SYNC beseitigt das herkömmliche V-SYNC-Stottern, das unterhalb der maximalen Bildwiederholfrequenz durch wiederholte Frames aufgrund einer verzögerten Frame-Ausgabe verursacht wird. Die Frametime-Spitzen wirken sich jedoch immer noch auf G-SYNC aus, da es nur spiegeln kann, was das System ausgibt. Wenn G-SYNC also für ein oder mehrere Frames nichts Neues zum Synchronisieren hat, muss es das vorherige Frame bzw. die vorherigen Frames wiederholen, bis das System die Ausgabe neuer Frames wieder aufnimmt, was zu der sichtbaren Unterbrechung führt, die als Stottern wahrgenommen wird.
Quelle

Es geht also um das Ausrichten des nächsten Bildes für den nächsten Scanout, der bei Frametimevarianzen nicht an der richtigen Stelle stattfindet. Ja, trotz adaptive sync, weil adaptive sync von diesen "Ausreißern" auf etwas schließt und einen Vorgang einleitet, wo das Bild an den ungewünschten Stellen gewechselt bzw. zu Zeichnen begonnen wird.

G-SYNC + V-SYNC “On”:
This is how G-SYNC was originally intended to function. Unlike G-SYNC + V-SYNC “Off,” G-SYNC + V-SYNC “On” allows the G-SYNC module to compensate for sudden frametime variances by adhering to the scanout, which ensures the affected frame scan will complete in the current scanout before the next frame scan and scanout begin. This eliminates tearing within the G-SYNC range, in spite of the frametime variances encountered.

Frametime compensation with V-SYNC “On” is performed during the vertical blanking interval (the span between the previous and next frame scan), and, as such, does not delay single frame delivery within the G-SYNC range and is recommended for a tear-free experience (see G-SYNC 101: Optimal Settings & Conclusion).

Nolag schrieb:
VSync off hat einfach den Vorteil, dass man schnell sieht, ob Adaptive Sync korrekt funktioniert und ob das Limit greift. Vsync kann das maskieren.
V-Sync maskiert hier nichts, vielmehr "beruhigt" es sogar sehr wilde Refreshratensprünge ggü. adaptive sync only. Ich kann mit Hilfe meiner OSD-Anzeige in jedem Spiel wunderbar sehen, dass mit

Adaptive Sync = AN
Fps-Limiter = gesetzt
V-Sync = AN

wunderbar die Refreshrate dynamisch angepasst wird und wie diese sich maximal auf den eingestellten Fps-Limiter oder einem ganzzahligen Vielfachen davon gesetzt wird.
 
  • Gefällt mir
Reaktionen: Cinquedea
FR3DI schrieb:
Für die V-Sync ON Experten unter uns;
Wichtig:

Mit G-Sync/FreeSync liegt klassisches V-Sync mit bekanntem Input Lag nur an
wenn die FPS die maximale Aktualisierungsrate (Hz) des Monitors erreichen
also z.B. bei 120FPS@120Hz. Darunter (also innerhalb der Sync Range) nicht !

Sprich:

Durch die Option Modus für geringe Latenz Ultra (Nvidia Reflex+Boost)
erstellt der Treiber ein Frame Limit unterhalb der max.Hz bei ca. 116 FPS.

und:

Durch den Frame Limiter im Treiber unter dem Punkt Max.Bildfrequenz
kann man diesen Wert auch selbst einstellen. Bei 120Hz z.B. auf 118 FPS.

Fazit:

Dadurch liegen nie 120 FPS an und kein klassisches V-Sync mit Input Lag.
 
  • Gefällt mir
Reaktionen: Jiddis und FR3DI
0ssi schrieb:
Mit G-Sync/FreeSync liegt klassisches V-Sync mit bekanntem Input Lag nur an
wenn die FPS die maximale Aktualisierungsrate (Hz) des Monitors erreichen
also z.B. bei 120FPS@120Hz. Darunter (also innerhalb der Sync Range) nicht !
Das würde den Bug erklären, warum bei aktiviertem G-Sync die Ruckler nur aufgetreten sind, wenn FPS = Monitor Frequenz war. Bei einem Framelimit von 82,90 oder 100 FPS hatte ich auch mit den vorherigen Treibern keine Probleme. Und darum gabs auch Tearing, sobald das FPS Limit aus war.
 
Nolag schrieb:
In der Praxis tritt das so gut wie nie auf, wenn man das Limit niedrig genug wählt und 1ms höher setzt als den Scanout.
Was bedeutet das in FPS Werten ? Ohne V-Sync hat man auf 120Hz mit G-Sync bei 116 oder 118FPS Limit
definitiv Tearing. Wenn man auf 100FPS limitiert weniger, bei 80FPS noch weniger und bei 60FPS ist es weg ?
Dann doch lieber V-Sync als zusätzliche "Frametimefehlerkorrektur" aktivieren um keine FPS zu verschenken.

Nolag schrieb:
VSync off hat einfach den Vorteil, dass man schnell sieht, ob Adaptive Sync korrekt funktioniert und ob das Limit greift.
Das Limit greift doch auch ohne V-Sync also Modus für geringe Latenz Ultra oder Max.Bildfrequenz.
Und wenn es durch Frametimeschwankungen trotz aktiviertem G-Sync (bei hohen FPS) in der Sync Range
ohne extra V-Sync trotzdem Tearing gibt wie soll man es dann von deaktiviertem G-Sync unterscheiden ?

Wer seinen Augen und seinem Spielgefühl nicht traut der kann sich anzeigen lassen ob G-Sync aktiv ist:

g-sync.jpg
 
shysdrag schrieb:
Hab noch den 551.23 für RTX 4070 super installiert. Mir sind keine Mikroruckler aufgefallen. Aber ja, updates schaden ja nicht.
//Edit: ah nur bei Vsync on, nutze noch den FPS Limiter mit VSync off. Nehme mal an die wenigsten spielen mit Vsync on.
Ich hoffe doch, dass auch der letzte Dau in 2024 endlich mitbekommen hat, das mit aktiviertem Gsync/Freesync "Vsync" im Nvidia Treiber auf "on" zu stehen hat (mit FPS Limit im Treiber auf Hz - 3)...
Ich finde es immer wieder geil, wenn Leute sich einen arschteuren Monitor kaufen und meinen ihre Bild ist flüssig, tearingfrei und hat wenig Input Lag und dann ist Vsync im Treiber aus und kein Limit gesetzt :D

https://blurbusters.com/gsync/gsync101-input-lag-tests-and-settings/15/
Ergänzung ()

Haldi schrieb:
Ahh.
Joa Vsync hab ich deaktiviert...
Da mein Monitor eigentlich 240Hz hätte und ich mit der 4090 sowieso seltenst an die 120FPS ran komme hab ich das gleich gelassen...
Mit aktiviertem Vsync/Freesync haben deine möglichen 240hz nichts damit zu tun, ob Vsync Sinn macht. Es macht damit einfach immer Sinn, weil Tearing bei flüssiger Wiedergabe vermieden wird - und nur dafür wurde Gsync entwickelt. Das geringere Inputlag war nur einen Nebenprodukt.

Aber wenn ich hier die vielen falschen Behauptungen und Begründung lese, obwohl wir in einem Nerd Forum sind, wird es wohl am der Zeit, dass Nvidia bestimmte Optionen ausgraut und erzwingt, wenn Gsync aktiviert wird...
Und es sollte vielleicht ein aufklärender Artikel dazu hier erscheinen @Jan , damit es zumindest wir Nerds es alle verstehen und besser wissen ;)
Ergänzung ()

0ssi schrieb:
Sprich:

Durch die Option Modus für geringe Latenz Ultra (Nvidia Reflex+Boost)
erstellt der Treiber ein Frame Limit unterhalb der max.Hz bei ca. 116 FPS.

und:

Durch den Frame Limiter im Treiber unter dem Punkt Max.Bildfrequenz
kann man diesen Wert auch selbst einstellen. Bei 120Hz z.B. auf 118 FPS.
Ich bin im Team "Doppelt hält besser" :D
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Cinquedea
0ssi schrieb:
erstellt der Treiber ein Frame Limit unterhalb der max.Hz bei ca. 116 FPS.

Ich tagelang gewundert und gesucht, warum ich in Warzone nur 138fps hab statt 144 - lag an genau jenem nVidia Latenz Boost Dingens…. 😅
 
rentex schrieb:
Ja, HAGS scheint mir immer noch sehr unbrauchbar.
Mein Problem ist, dass ohne HAGS (W10) die Encoderzeit vom Sunshine von 2ms auf 6-8ms hoch geht... Warum auch immer. Aktuell ist es bei mir deswegen aktiv.
Ergänzung ()

ChrisMK72 schrieb:
Ist das ein Trollversuch? Anders kann ich mir solche Aussagen (nicht nur von dir) hier einfach nicht mehr erklären.

PS: Will aber niemand auf den Leim gehen und bin daher raus aus dieser Diskussion hier, bevor es noch Punkte für mich hagelt. ;) Ich wünsche allen einen angenehmen Abend und weiter eine erfrischende (wie auch immer) Diskussion.
Sagte der Troll... Vsync ON (im Treiber!) hat mit Gsync/Freesync und Framelimit (im Treiber, entweder als festen Wert oder über ULL) keinen Nachteil, nur Vorteile. Wenn du das nicht glaubst ist das dein Problem, aber stell hier nicht andere als Troll dar.
Spiegel und so... willkommen auf Ignore.
Ergänzung ()

FR3DI schrieb:
Für die V-Sync ON Experten unter uns;
Typischer Fall von "Gelesen, nicht verstanden und weiterhin überzeugt Recht zu haben"...
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Cinquedea
@ripa
Und dein Leselimit scheint übrigens für heute auch erreicht und oder wie erklärst du dir jene Zustimmung meinerseits zu jenen vorherigen Beitrag von @0ssi ?

Du quasselst also mit letzteres, an der Realität vorbei.

Gruß Fred.
 
ShiftC schrieb:
Das alles hat aber zunächst nichts mit dem Zeitpunkt des Bildwechsels zu tun. Mit V-Sync, egal ob alleine oder parallel zu adaptive sync,
In der Adaptive Sync Range ist nur Adaptive Sync aktiv. VSync findet nie parallel zu Adaptive Sync statt.
ShiftC schrieb:
Blur Busters erklärt genau, warum es dennoch zu Tearing kommt.
Blur Busters beschreibt, dass man von der durchschnittlichen BIldrate, die einem angezeigt wird, nicht auf die Maximalfrequenz schließen kann. Es kann natürlich zu Tearing kommen obwohl die gemittelte Bildrate in der GSync Range ist. Das ist eine Trivialität. Man muss sich schon die Frametimes ansehen. Ist die Frametime aber oberhalb der Zeit für den Scanout, findet auch ohne VSync kein Tearing statt.
ShiftC schrieb:
Adaptive Sync berechnet in Abhängigkeit von den aktuellen Frametimes die benötigte Zeitspanne zwischen zwei Bildwechsel und beeinflusst so die Refreshrate, d.h. wie OFT der Scanout stattfinden soll.
Adaptive Sync macht keine Annahmen über die Bildrate. Die Bildrate wird vom Buffer-Flip der Anwendung gesteuert. Kommt der Flip nicht, dann greift die LFC und das Bild wird wiederholt. Kommt der Flip während des Scanout, dann gibt es ohne VSync Tearing. Mit VSync wird in diesem Fall auf das Ende des Scanout gewartet.
ShiftC schrieb:
, dass mit

Adaptive Sync = AN
Fps-Limiter = gesetzt
V-Sync = AN

wunderbar die Refreshrate dynamisch angepasst wird und wie diese sich maximal auf den eingestellten Fps-Limiter oder einem ganzzahligen Vielfachen davon gesetzt wird.
Das funktioniert auch ohne VSync.

Die Empfehlung VSync zu verwenden ist ja richtig, aber hier reflexartig Leuten im Prinzip Blindheit vorzuwerfen, die auf einem 240Hz Monitor bei ausgeschaltetem VSync ein 120 fps Limit gesetzt haben, ist nicht in Ordnung. Es ist zwar korrekt, dass nur mit aktivem VSync Tearing wirklich verhindert werden kann. Der Umkehrschluss, dass Tearing zwingend auftritt, wenn man VSync deaktiviert und nur einen Framelimiter verwendet, ist aber falsch.
 
ripa schrieb:
Ich hoffe doch, dass auch der letzte Dau in 2024 endlich mitbekommen hat, das mit aktiviertem Gsync/Freesync "Vsync" im Nvidia Treiber auf "on" zu stehen hat (mit FPS Limit im Treiber auf Hz - 3)...
Ich finde es immer wieder geil, wenn Leute sich einen arschteuren Monitor kaufen und meinen ihre Bild ist flüssig, tearingfrei und hat wenig Input Lag und dann ist Vsync im Treiber aus und kein Limit gesetzt :D

https://blurbusters.com/gsync/gsync101-input-lag-tests-and-settings/15/
Ich persönlich tu mir mit Empfehlungen die offensichtlich ein copy+paste eines bereits vor 2 Tagen geposteten Vorschlags sind und zum Rest nur aus Beleidigungen bestehen schwer. Vor allem wenns direkt unter dem zitierten Post steht. Aber mach ruhig! Ich bin mir sicher viele Menschen sind dankbar für deine Mühen.

https://www.computerbase.de/forum/t...kroruckler-und-stottern.2183114/post-29106945
 
LiFeSII schrieb:
Ich bin immer noch auf den 537.58 Treiber - alles danach war für mich Müll. Update auch nur wenn es unbedingt notwendig ist.
DeMeP schrieb:


Der Artikel gibt im oberen Teil eine mögliche Antwort. 536 läuft auch gut mit den paar aktuelleren Games, ohne Ray Reconstruction(Hardware) in Cyberpunk, die ich so zocke.

-FINALS (nur 1h gespielt)
-Skull and Bones Beta
-Witcher 3 NG v4.04 mit RT
-Portal: Revolution
-Trine5
-Broken Arrow Playtest
-Tempest Rising Demo
 
Zuletzt bearbeitet: (Geschachtelte Zitate gingen nicht, Gamesliste)
  • Gefällt mir
Reaktionen: DeMeP
Man sollte echt mal einen FAQ anpinnen wie man und was mann am besten einstellt.
 
Für Nvidia G-Sync:

Max.Bildfrequenz:

120Hz auf 117FPS
144Hz auf 140FPS
165Hz auf 160FPS

Modus für Geringe Latenz: Ultra
120Hz = 116FPS
144Hz = 138FPS
165Hz = 15XFPS

Vertkale Synchronisierung: Ein
 
ShiftC schrieb:
Ja, so ist es. Ein 144 Hz Monitor, selbst wenn er während des adaptive syncing grade auf 76 Hz geschaltet ist, hat immer noch eine fixe Scanoutzeit von 6,94 ms (sofern in den Anzeigeeinstellungen des Treibers 144 Hz ausgewählt wurde).

Sicher, dass das korrekt ist? Bisher hatte ich es anders verstanden.

Stichwort Overdrive.
Bei LCD Monitoren kommt es zu overshoot, wenn bei geringen Frequenzen wie z.B. 60 Hz der Overdrive zu stark eingestellt ist. Die gleiche Overdrive Stufe kann aber bei z.B. 144 optimal sein.

Gerade bei Monitoren mit Gsync Modul war daher eines der Verkaufsargumente, der variable Overdrive, der für jede Frequenz optimal ist.
Mittlerweile bekommen die hersteller es auch ohne Modul immer häufiger hin, dass der Overdrive über die gesamte VRR Range passt, aber der Punkt auf den ich hinaus will ist, dass ein variabler overdrive oder ggf. eine manuelle Anpassung je nach anliegender Framerate gar nicht notwendig wäre, wenn das Display den Scanout stets mit der Maximalfrequenz machen würde. Also muss ich doch davon ausgehen, dass auch die Scanout Zeit sich anpasst und sich ein 144 Hz Monitor im VRR Betrieb bei 60 FPS genauso verhält, als wenn ich 60 Hz einstellen würde.

Ich kenne zwar den Grund nicht, warum man den Scanout nicht mit der Maximalfrequenz macht, aber ich lasse mich da auch gerne eines besseren belehren..
Aber das Verhalten mit dem Overdrive kann ich mir nur durch eine variable scanout Zeit erklären.
 
  • Gefällt mir
Reaktionen: ShiftC
Bei mir hat der Treiber was gebracht. Alle Vsync und stutter Probleme sind, bis jetzt zumindest, weg. Das ist der erste Treiber seit dem 537.58 den ich verwenden kann. What a ride... Hat zwar gedauert, aber trotzdem Danke.
 
  • Gefällt mir
Reaktionen: Ecoli86 und Mr. Vega
Warum liefert nviida bittesehr ohne Not so schlechte Treiber aus das sie mit einem hotfix nachhelfen müssen.

Wenn man den versammelten Fanbois glauben will, sind schlechte Treiber die Domäne von AMD :evillol: :freak:
 
Mimir schrieb:
Sicher, dass das korrekt ist? Bisher hatte ich es anders verstanden.

Ich wusste das früher auch nicht, aber ja, ist tatsächlich so. Die Scanoutgeschwindigkeit ergibt sich nicht durch die momentane, sondern durch die maximale Refreshrate des Monitors und ist fix. Mit der variablen Refreshrate wird gesteuert, wie oft der Scanout pro Sekunde von statten findet.

Auszug aus Blurbusters:
With a fixed refresh rate display, both the refresh rate and scanout remain fixed at their maximum, regardless of framerate. With G-SYNC, the refresh rate is matched to the framerate, and while the scanout speed remains fixed, the refresh rate controls how many times the scanout is repeated per second (60 times at 60 FPS/60Hz, 45 times at 45 fps/45Hz, etc), along with the duration of the vertical blanking interval (the span between the previous and next frame scan), where G-SYNC calculates and performs all overdrive and synchronization adjustments from frame to frame.
 
  • Gefällt mir
Reaktionen: Mimir
Ich frage mich , ob auch der Unterschied zwischen Win 10 und 11 eine Rolle spielt, und ob die Kombi AMD mit Nvidia oder Intel mit Nvidia entscheident ist. Ich mit Win 11 und 13600k mit 4080 habe immer noch leichte Probleme mit dem Hotfix. Daher wieder zurück auf den 537.58
 
Ich habe den HotFix am Donnerstag mal kurz angetestet und er ist auf jeden Fall besser als alle vorherigen andere 54x.yz und 551.yz Treiber. Ich will aber noch ein paar weitere Spielsessions machen, um es zu bestätigen. Daher habe ich noch nicht bei der Umfrage abgestimmt.
 
Zurück
Oben