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

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.

https://blurbusters.com/gsync/gsync101-input-lag-tests-and-settings/15/
Die Aussagen von Blur Busters, dass ein Limiter nicht dazu geeignet sei, die Bildrate in der Sync-Range zu halten sind rein akademischer Natur. In eigenen Experimenten hat Blur Busters selbst wiederholt nachgewiesen, dass Limiter auf 1ms genau sind. Setzt man also den Limiter so, dass man 1ms oberhalb der Zeit für den Scanout liegt, ist Tearing praktisch ausgeschlossen.


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?
The answer is frametime variances.


“Frametime” denotes how long a single frame takes to render. “Framerate” is the totaled average of each frame’s render time within a one second period.


At 144Hz, a single frame takes 6.9ms to display (the number of which depends on the max refresh rate of the display, see here), so if the framerate is 144 per second, then the average frametime of 144 FPS is 6.9ms per frame.


In reality, however, frametime from frame to frame varies, so just because an average framerate of 144 per second has an average frametime of 6.9ms per frame, doesn’t mean all 144 of those frames in each second amount to an exact 6.9ms per; one frame could render in 10ms, the next could render in 6ms, but at the end of each second, enough will hit the 6.9ms render target to average 144 FPS per.


So what happens when just one of those 144 frames renders in, say, 6.8ms (146 FPS average) instead of 6.9ms (144 FPS average) at 144Hz? The affected frame becomes ready too early, and begins to scan itself into the current “scanout” cycle (the process that physically draws each frame, pixel by pixel, left to right, top to bottom on-screen) before the previous frame has a chance to fully display (a.k.a. tearing).


G-SYNC + V-SYNC “Off” allows these instances to occur, even within the G-SYNC range, whereas G-SYNC + V-SYNC “On” (what I call “frametime compensation” in this article) allows the module (with average framerates within the G-SYNC range) to time delivery of the affected frames to the start of the next scanout cycle, which lets the previous frame finish in the existing cycle, and thus prevents tearing in all instances.


And since G-SYNC + V-SYNC “On” only holds onto the affected frames for whatever time it takes the previous frame to complete its display, virtually no input lag is added; the only input lag advantage G-SYNC + V-SYNC “Off” has over G-SYNC + V-SYNC “On” is literally the tearing seen, nothing more.


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?

G-SYNC adjusts the refresh rate to the framerate. If the framerate reaches or exceeds the max refresh rate at any point, G-SYNC no longer has anything to adjust, at which point it reverts to V-SYNC behavior (G-SYNC + V-SYNC “On”) or screen-wide tearing (G-SYNC + V-SYNC “Off”).
As for why a minimum of 2 FPS (and a recommendation of at least 3 FPS) below the max refresh rate is required to stay within the G-SYNC range, it’s because frametime variances output by the system can cause FPS limiters (both in-game and external) to occasionally “overshoot” the set limit (the same reason tearing is caused in the upper FPS range with G-SYNC + V-SYNC “Off”), which is why an “at” max refresh rate FPS limit (see part 5 “G-SYNC Ceiling vs. FPS Limit” for input lag test numbers) typically isn’t sufficient in keeping the framerate within the G-SYNC range at all times.

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


Because, with G-SYNC enabled, each performs a role the other cannot:
  • Enabling the V-SYNC option is recommended to 100% prevent tearing in both the very upper (frametime variances) and very lower (frametime spikes) G-SYNC range. However, unlike framerate limiters, enabling the V-SYNC option will not keep the framerate within the G-SYNC range at all time.
  • Setting a minimum -3 FPS limit below the max refresh rate is recommended to keep the framerate within the G-SYNC range at all times, preventing double buffer V-SYNC behavior (and adjoining input lag) with G-SYNC + V-SYNC “On,” or screen-wide tearing (and complete disengagement of G-SYNC) with G-SYNC + V-SYNC “Off” whenever the framerate reaches or exceeds the max refresh rate. However, UNLIKE THE V-SYNC OPTION, FRAMERATE LIMITERS WILL NOT PREVENT TEARING.



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.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: MurdocNicalls, rentex, ShiftC und 7 andere
Mr. Vega schrieb:
Wenn man sich die Open/Known Issues der Treiber Erscheinungen anschaut nehmen die sich am Ende des Tages nichts.

oh doch nehmen sie sich gewaltig, sonst hätte ich nicht die letzten 6 amd karten zurück schicken müssen..
Ergänzung ()

FR3DI schrieb:
Für die V-Sync ON Experten unter uns;

hey du experte, dir ist schon bewusst das man vsync mit tripple buffering oder auf schnell stellen kann? somit ist der input lag geschichte ;)

Und über GSYNC/Freesync wollen wir gar nicht erst anfangen zu reden aber du kennst wohl nur die alte standard-technik von vsync, die ist aber gut 20 jahre alt mein freund.
 
  • Gefällt mir
Reaktionen: MoinWoll und FR3DI
Es ist doch unstrittig, dass Tearing auftritt, wenn man die Sync-Range verlässt. Innerhalb der Sync-Range gilt aber immer folgendes:
Within its range, G-SYNC is the only syncing method active, no matter the V-SYNC “On” or “Off” setting.
Mit einem korrekt gesetzten Limiter verlässt man die Sync-Range nicht:
As for why a minimum of 2 FPS (and a recommendation of at least 3 FPS) below the max refresh rate is required to stay within the G-SYNC range
Das folgende muss man natürlich schreiben, weil es passieren kann.
can cause FPS limiters (both in-game and external) to occasionally “overshoot” the set limit
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.
VSync off hat einfach den Vorteil, dass man schnell sieht, ob Adaptive Sync korrekt funktioniert und ob das Limit greift. Vsync kann das maskieren.
 
  • Gefällt mir
Reaktionen: ChrisMK72
Ardadamarda schrieb:
Doom Eternal beweist das Gegenteil. Läuft butterweich und das unter Vulkan. Es ist also machbar.
Leider ist das das einzige Low-Level-API-Beispiel was ich kenne, das weitestgehend stotterfrei ist (auch hier hatte ich an einigen wenigen Stellen Traversal-Stutter). Vermutlich wurde hierauf bei der Entwicklung von Anfang an Wert gelegt. Ich denke die allermeisten Entwickler bauen erstmal das Spiel und schauen am Ende, wenn überhaupt, ob es stottert und was man dann noch machen kann ohne alles nochmal grundlegend zu überarbeiten. Zu dem Zeitpunkt springt dann vermutlich das Management dazwischen und sagt, dass es so released wird wie es ist, anstatt nochmal ein Jahr an den Stotterern zu arbeiten, die für die viele offenbar tolerierbar oder gar nicht wahrnehmbar sind.

Ich hoffe, dass gerade bei der Unreal Engine 5, die in Zukunft vermutlich jedes zweite AAA-Spiel verwenden wird, ein großer Fokus darauf gelegt wird den Entwicklern bzgl. Stottern so viel Arbeit wie möglich abzunehmen. Leider stottern die bisherigen UE5-Spiele aber auch munter vor sich hin. Das letzte Beispiel, das ich gespielt habe, war RoboCop, dort stottert es leider alle paar Meter.
 
Zuletzt bearbeitet:
FR3DI schrieb:
Ist das etwa verkehrt?
Es ist ein anderer Ansatz. Ich persönlich mag es lieber alles an einem Ort zu haben und nicht gerne unzählige unterschiedliche Programme für einzelne Funktionen auf dem PC.


FR3DI schrieb:
Der ehemalige CCC war ehemals nicht anders. Aber mit Generation RGB a la Kinderdisco, hat sich das geändert
Der Kontext entzieht sich Mir hier.
FR3DI schrieb:
89% aller Leute die einen Rechner bedienen, Wissen nicht mal was OC ist. Und ja, UV ist ebenfalls OC.
Und das ist die Begründung das ein Unternehmer wie Nvidia es nicht schafft solche Tools selbst auf die Beine zu stellen über Jahre?
FR3DI schrieb:
Inklusive Werbung
Die man in den Einstellungen vollständig deaktivieren kann.
 
  • Gefällt mir
Reaktionen: anarchie99, MoinWoll und FR3DI
Nolag schrieb:
Es ist doch unstrittig, dass Tearing auftritt, wenn man die Sync-Range verlässt. Innerhalb der Sync-Range gilt aber immer folgendes:

Mit einem korrekt gesetzten Limiter verlässt man die Sync-Range nicht:

Das folgende muss man natürlich schreiben, weil es passieren kann.

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.
VSync off hat einfach den Vorteil, dass man schnell sieht, ob Adaptive Sync korrekt funktioniert und ob das Limit greift. Vsync kann das maskieren.

Nicht "passieren kann". Es passiert ständig wenn du nahe der Maximalfrequenz bist.
Du musst das FPS Limit relativ niedrig im Verhältnis zur Maximalfrequenz setzen, um Tearing "innerhalb" der Sync Range zu vermeiden.

Damit kannst du deinen Monitor eben nicht mit hohen Framerates auslasten und hast natürlich bei geringeren Frameraten auch effektiv höheren Inputlag. Also wozu das ganze? Einfach Vsync + Limiter an und das Thema ist gegessen.

Und wenn Adaptive Sync nicht greifen würde sieht man das sofort am Ruckeln.
 
  • Gefällt mir
Reaktionen: ShiftC und MoinWoll
DaHell63 schrieb:
Weil das ja so super im AMD Treiber funkioniert
Was definitiv super funktioniert, ja.
DaHell63 schrieb:
Erst mit dem MPT (Drittanbieter) hat man bei AMD einen Vorteil.
Das More Power Tool liest Vbios Daten aus/überschreibt diese und setzt/verändert Registry Einträge dafür. Das kann man wohl kaum mit dem Afterburner vergleichen. Und ich persönlich bin auch kein Freund von Programmen die Firmware Sicherheits Werte überschreiben.
DaHell63 schrieb:
Die Möglichkeiten mit dem AB sind da für eine Nvidia Karte erheblich größer.
Das einzige was der AB mit Nvidia GPUs an Mehrwert bietet ist der Curved Editor im Vergleich.

Und hier sind wir wieder beim Thema warum Nvidia sowas nicht selbst und von Haus aus anbietet.

Zudem die Entwicklung vom Afterburner nun bekannterweise schon länger stagniert.
Man kann nur hoffen das die Entwicklung weiter geht für Nvidia User die den nutzen und in Zukunft für neuere Karten nutzen möchten.
Ergänzung ()

PTS schrieb:
oh doch nehmen sie sich gewaltig, sonst hätte ich nicht die letzten 6 amd karten zurück schicken müssen..
Ist natürlich ohne Kontext einfach so in den Raum geworfen jetzt schwierig.
Und auch etwas unglaubwürdig (ohne dazugehörigen Kontext halt) das 6x zurück schicken immer mit dem dem Treiber zutun haben soll.
 
Zuletzt bearbeitet von einem Moderator:
  • Gefällt mir
Reaktionen: Snoop7676 und anarchie99
Mr. Vega schrieb:
Und das ist die Begründung das ein Unternehmer wie Nvidia es nicht schafft solche Tools selbst auf die Beine zu stellen über Jahre?
Sehe ich auch so. Es wäre super wenn NVIDIA endlich UV/OC und Monitoring über den Treiber (ohne GeForce Experience und Account-Zwang) anbieten würde. Vor allem da der MSI Afterburner leider auch Mikroruckler erzeugt.

Die NV-CP-Oberfläche ist mir allerdings egal, da wird einmal alles eingestellt und dann nur wieder reingeschaut, wenn aus irgendeinem Grund ein neuer Treiber komplett frisch installiert werden muss, sodass die Einstellungen zurückgesetzt werden. Und selbst dann ist mir wurscht, ob das wie Windows XP oder Windows 11 aussieht.
 
  • Gefällt mir
Reaktionen: Mr. Vega und anarchie99
myfan schrieb:
Und du lebst in keiner Bubble mit so einer Aussage wie dein ganzer Post ?

Schau mal über den Tellerrand, ich für meinen Teil hab beides zu Hause.
Ich bin Teil der Techbubble ja.

Ich habe auch noch eine 3090 als Ersatzkarte hier. War auch längere Zeit im Professionellen Einsatz.
Ergänzung ()

MoinWoll schrieb:
Sehe ich auch so. Es wäre super wenn NVIDIA endlich UV/OC und Monitoring über den Treiber (ohne GeForce Experience und Account-Zwang) anbieten würde. Vor allem da der MSI Afterburner leider auch Mikroruckler erzeugt.
Genau das ist der Punkt.
Vorallem, weil wie bereits in einem anderen Kommentar geschrieben die Entwicklung von AB stagniert. Worauf weichen dann, versierte User aus, wenn Sie den gleichen Funktionsumfang möchten, der AB aber zum Bsp nicht mehr weiterentwickelt wird.
Ergänzung ()

Sinatra81 schrieb:
Und es gibt Trolle, die klicken:

„Nein, die Ruckler-Probleme bleiben bestehen.“, obwohl sie keine nVidia Karte haben.
Definitiv. Leider ist auch das so.
 
Zuletzt bearbeitet von einem Moderator:
Mr. Vega schrieb:
Worauf weichen dann, versierte User aus, wenn Sie den gleichen Funktionsumfang möchten, der AB aber zum Bsp nicht mehr weiterentwickelt wird.
Eine Option wäre Lüftersteuerung mit Fan Control, Monitoring mit CapframeX und Übertakten mit GeForce Experience (funktioniert mehr schlecht als recht). Aber das ist einfach viel aufwändiger und eingeschränkter (auf GFE bezogen) als die bisherige Afterburner-Funktionalität.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Mr. Vega
Mr. Vega schrieb:
Zudem die Entwicklung vom Afterburner nun bekannterweise schon länger stagniert.
Nur weil man offiziell hier nur noch den MSI Afterburner 4.6.5 laden kann bedeuted das ja nicht, dass es nicht weitergeht.
Momentan bin ich bei der Version 4.6.6 Beta 2
AB.jpg

 
Mr. Vega schrieb:
Vorallem, weil wie bereits in einem anderen Kommentar geschrieben die Entwicklung von AB stagniert. Worauf weichen dann, versierte User aus, wenn Sie den gleichen Funktionsumfang möchten, der AB aber zum Bsp nicht mehr weiterentwickelt wird.
Wird der AB nicht eigentlich analog zum Rivatuner entwickelt? War da nie so tief drin, habs immer einfach nur genutzt. Aber für den Rivatuner gab es gestern oder vorgestern ein ziemlich großes Update. Beim AB war ich auch schon oft mit den Beta Versionen unterwegs. Aktuell bin ich aber nach wie vor bei 4.6.5
 
Habs gefunden.... erledigt....
taucht als letzte Datei auf,:pcangry: obwohl es die neueste ist...


Hallo,

wo kann man denn die Hotfixdatei geforce-551-46-hotfix runterladen?
Bei Nvidia gibt es nur die 551.31 und hier finde ich auch keine mit 551.46?

Danke im voraus
 
Zuletzt bearbeitet:
DaHell63 schrieb:
Nur weil man offiziell hier nur noch den MSI Afterburner 4.6.5 laden kann bedeuted das ja nicht, dass es nicht weitergeht.
Momentan bin ich bei der Version 4.6.6 Beta 2
Anhang anzeigen 1452417

Interessant. Woher stammt diese Version? Weder vom offiziellen Dev, Msi oder Guru3D die das Projekt supporten. Hier wäre ich vorsichtig. Die 4.6.6 Beta wird mit bei einer Suche nur von einer chinesischen Patreon Seite angezeigt. Hier bezweifle ich das es sich um eine offizielle Weiterentwicklung handelt.

Umsonst gibt es diese Warnmeldung sicherlich nicht.

Gerne aber mal Feedback. Man lernt ja nie aus.

Edit: @Lurtz hatte da den entsprechenden Link. Dann mal schauen wann die nächste Finale Version erscheint.
 

Anhänge

  • AB Warning.jpg
    AB Warning.jpg
    20 KB · Aufrufe: 94
Zuletzt bearbeitet von einem Moderator:
Phear schrieb:
Wird der AB nicht eigentlich analog zum Rivatuner entwickelt? War da nie so tief drin, habs immer einfach nur genutzt. Aber für den Rivatuner gab es gestern oder vorgestern ein ziemlich großes Update. Beim AB war ich auch schon oft mit den Beta Versionen unterwegs. Aktuell bin ich aber nach wie vor bei 4.6.5
Der Entwickler vom AB und Riva Tuner entwickelt selbst nur noch den Riva Tuner weiter. Der Afterburner wird schon länger noch von MSI über Gruru3D weiterentwickelt. Das war mein letzter Stand. Die letzte finale Version ist halt schon 9 Monate alt. Aber es soll weiterhin im Guru3D Forum veröffentlichte Beta geben.

https://www.tweakpc.de/news/49020/msi-afterburner-aktuelle-probleme-bei-der-programmierung/

Hab zum Thema gerade nur diesen Artikel noch gefunden. Es gab aber entsprechend auch welche von CB oder PCGH.
Ergänzung ()


EDIT: siehe Kommentare von Lurtz für aktuelle Infos
Lurtz schrieb:
Danke für die Information.
 
Zuletzt bearbeitet von einem Moderator:
Das stimmt nicht (mehr), Unwinder entwickelt AB ganz normal weiter, ebenso RTSS. Es stand nur eine Zeit lang die Frage im Raum wie er von MSI aufgrund der Sanktionen gegen Russland weiter kompensiert werden kann.
 
  • Gefällt mir
Reaktionen: Mr. Vega
Ah okay. Super. Dann hat sich das geändert. Schade das man dazu im Netz nichts aktuelles findet. Danke nochmals für deine Aufklärung. Ich finde Nvidia sollte ich hier beteiligen. (oder tun sie das bereit?) Unter dem technischen und Entwicklunger Aspekt ist das Tool wirklich gut. Ich habe mir den Link auch mal gespreichert.
 
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.
 
FR3DI schrieb:
Ich danke NVIDIA für das schlichte Design.
MrHeisenberg schrieb:
Wenn der Treiber dafür stabiler läuft als der von AMD, dann nehme ich das altbacken UI gern in Kauf ;)
usernamehere schrieb:
Vermisse ich jeden Tag, Nvidia hat einfach richtig hässliche und langweilige Software. Und da auch noch seit Jahren die gleiche:freak:
Capthowdy schrieb:
Was spielt ihr eigentlich immer im Treiber rum dass da so gejammert wird? Ich sehe den vielleicht 5x im Jahr für ein paar Sekunden und das wars, mir völlig egal wie der aussieht.
Hakt nicht aufeinander herum, sondern bitte auf nVidia. Das, was sie machen, ist eine Frechheit; denn das Treiberpanel ist technisch schlecht.
  1. Es bietet kaum Platz, entsprechend viel muss unnötig gescrolled werden.
  2. Es performed mieß.
  3. Diverse Optionen fehlen, für sie braucht es den Nvidia Profile Inspector.
Die Nvidia-Systemsteuerung ist in etwa so frech wie Microsoft mit den Windows-Systemsteuerungen, von denen trotz den Giganto-Gewinnen der Firmen keine einzige mal fertig entwickelt wird.

Und nein, ich hätte nichts dagegen, wenn sich Nvidia oder Microsoft vor zwanzig Jahren für ein Design entschieden und das danach nutzerorientiert durchgezogen hätte.
 
  • Gefällt mir
Reaktionen: FR3DI, rentex, anarchie99 und eine weitere Person
Zurück
Oben