Grundlagenartikel NVIDIA NULL und Reflex vs. AMD Anti-Lag und Radeon Boost – was ist besser? Latenzen in der Praxis!

Redaktion

Artikel-Butler
Mitarbeiter
Mitglied seit
Aug 6, 2018
Beiträge
1.748
Bewertungspunkte
8.479
Punkte
1
Standort
Redaktion
Was lange währt – wird meistens gut. Für den heutigen Test mit der Frage “NVIDIA NULL und Reflex vs. AMD Anti-Lag und Radeon Boost, was funktioniert besser?” habe ich mir allerdings extra viel Zeit genommen. Seit einiger Zeit schreibe ich ja bereits über das Thema Latenzen und es gab auch es schon den ein oder […]

Hier den ganzen Artikel lesen
 
Hallo Fritz & Co., danke für den Test und zugehörigen Aufwand.

Ich hätt dazu noch ne generelle Bitte: ihr beschreibt immer in großem Kasten euer Testsystem, gerade dass dort nicht auch noch das Mauspad mit beschrieben ist :) aber die verwendeten Mess Metriken werden nicht explizit und standardisiert erklärt. Gut, FPS kenn ich, aber wenn ich jetzt aus dem Stehgreif Frametimes oder Systemlatenz erklären müsste, dann müsst ich schon erstmal schlucken. Ich gehör jetzt schon wohl eher zu den PC-Durchblickern und tu mich bei euren Test dennoch oft mal etwas schwer mit der Einordnung verwendeter Metriken - und eure Leser sind vermutlich weit vielschichtiger als wir paar Freaks, die sich halt hauptsächlich zu Wort melden.

Ich fänds also gut, wenn ihr solche Kennwerte analog zum Testsystem auch mal sauber erklären würdet, in welcher Einheit werden die gemessen, was bedeuten die Metriken, was beeinflussen sie, gibts da bestimmte Schwellen, die nicht unter- oder überschritten werden sollten. Wenn die Texte und Boxen dazu einmal gemacht sind, lassen die sich ja bei jedem weiteren Test einfach unters Testsystem kopieren (mit der Auswahl an verwendeten Metriken).
 
Auf die Gefahr hin,mich gleichzeitig bei AMD und NVIDEA Fan's unbeliebt zu machen,möchte ich einen Gedanken einfließen lassen.
Generell frage ich mich,ob diese FPS Spirale der einzig denkbare Weg ist?

Gewinne ich,weil meine Latenzen und der Ping einfach besser sind,oder weil ich der bessere Spieler bin?
Ist der Gedanke eines Fairplays,wie immer dieser erreicht werden könnte,der Hardwareaufrüstung gewichen?

OK....
Betroffen bin ich von dieser Entwicklung eigentlich gar nicht,da ich höchstens mal auf Steam Autorennen fahre.
„Shooter“ und ähnliche Genres sind nicht so mein Ding...
Würde mich freuen,wenn mein Xplane auf drei 4K-Bildschirmen irgendwann mal mit höchster Qualitätsstufe
und 60 FPS laufen würde.

Gäbe es also im Sinne eines Fairplays nicht die Möglichkeit der Nivellierung der teilnehmenden Spieler
in Onlinespielen?
Eine KI welche Ping und Latenzen ausliest und dann für Chancengleichheit sorgt?

Ist dieser Gedanke zu abwegig?
Vielleicht bin ich vollkommen OUT OF TIME mit diesem Gedanken?

Meine Grundeinstellung des Fairplays ist aber seit meiner frühesten (sportlichen) Jugend Bestandteil
meiner Person.
Mich persönlich würde der Gedanke stören, nur aufgrund der besseren Hardware zu gewinnen...
Wie gesagt,nur ein Gedanke...

Ich ziehe mal meine schusssichere Weste an....:)
 
Zuletzt bearbeitet :
Hier wird immer noch ignoriert, dass die Latenz nicht allein abhängig von der GPU ist, das mit der GPU also fast gar nichts zu tun hat (inklusive deren Treibern), den Lesern hier aber gerne eingeredet wird. Die Gamelatenz ist vor allem abhängig von der CPU und der Render Queue, zusätzlich von der Pooling Rate der Mouse und dem Inputlag des Display's. Die GPU spielt dabei nur eine unwesentliche Rolle, Änderungen über den Treiber der GPU wirken aber allgemein.

Also Input (Mouse)=>CPU=>Renderqueue=>GPU=>Monitor! Dabei zeichnet Nvidia besonders niedrige Werte, wenn die Hardware RLA kompatibel ist (und muss es auch sein), sonst könnte sogar AMDs Variante Vorteile bieten. Das Texturing spielt dabei keine wesentliche Rolle, die Berechnungszeit verkürzt sich jedoch wenn die Bildrate steigt.

Die gemessenen Werte gelten also für das Testsystem im getesteten Spiel Overwatch und nicht allgemein, daher sind allgemeine Fazit auch nicht aussagekräftig. Ich vermute mal daher stellt man die Messreihen mit explizieter Erläuterung erst gar nicht online. Fazit ist eher, eine höhere CPU Leistung und Threadoptimierung kann Techniken wie Reflex und Antilag beschleunigen. Das AMD da einige Nachteile im CPU Limit unter DX11 hat, ist bekannt. Trotzdem wird es immer wieder getestet. Warum auch immer...

Das heißt also letztlich, ich kann die Pipeline aus Eingabe=>Berechnung=>Befehl=>Bild=>Visuelle Ausgabe schon bei der Eingabe abschießen (und das liegt auch daran wie schnell "ich selbst" jeweils "klicke"=>ergo spielt der, der vor dem Bildschirm sitzt auch noch eine wesentliche Rolle). Da kann die GPU mal gar nichts dafür und auch kein Hersteller. Zumal per Engine auch gerne auf Hardware optimiert wird (UE4 unter DX11), darauf hat ein CPU oder GPU Hersteller nur unwesentlichen Einfluss, sondern wählen Entwickler die Variante die am Besten zum gewollten Ergebnis passt. Das alles per Treiber zu "cheaten" ist faktisch unmöglich und ist unter DX12 auch nicht mehr erwünscht.

Ich müsste also für auswertbare Messreihen garantieren, dass ich immer gleiche Eingabezeiten erreiche bzw. auf den Bildinhalt immer gleichschnell reagiere, wie nur? Das Ganze setzt sich für alle Stufen in der Pipeline fort, sowie Hintergrundprozesse usw..
 
Zuletzt bearbeitet von einem Moderator :
Danke für den Test @FritzHunter01
Kann mich hier aber generell auch @ipat66 anschließen. Mache um reine Online- und/oder Multiplayer seit deren Bestehen einen großen Bogen. Kann mich dafür einfach nicht begeistern. Und obwohl ich Fallout und die Elder Scrolls-Reihe ohne Ende gespielt habe, und das auch noch tue, gehen die jeweiligen Online-Varianten gar nicht bei mir.
Ich muss jetzt auch nicht unbedingt Eyecandy in den Spielen haben, wenn ich keinen Augenkrebs kriege, reicht mir das. Und meine Schmerzgrenze ist da sicher höher als bei den reinen Gamern und/oder Enthusiasten. Dann lieber ein Flüstern beim Zocken als einen Düsenjet.
Und egal, welches Spiel ihr da in den letzten 1-2 Jahren zum Testen heran gezogen habt: ich habe bisher außer dem Witcher 3 keines davon gespielt. Das einzige, dass ich zumindest noch gekauft habe, ist Cyberpunk. Das aber auch schon ein halbes Jahr vor Erscheinen, habe es aber noch nicht mal bei GOG heruntergeladen.
War vielleicht auch keine schlechte Idee, bei dem, was man von den Anfangsschwierigkeiten so gelesen hat.

Deswegen sind solche Tests aber trotzdem immer interessant, auch wenn es mich im Grunde nach wenig betrifft.
 
Hier wird immer noch ignoriert, dass die Latenz nicht allein abhängig von der GPU ist, das mit der GPU also fast gar nichts zu tun hat (inklusive deren Treibern), den Lesern hier aber gerne eingeredet wird. Die Gamelatenz ist vor allem abhängig von der CPU und der Render Queue, zusätzlich von der Pooling Rate der Mouse und dem Inputlag des Display's. Die GPU spielt dabei nur eine unwesentliche Rolle, Änderungen über den Treiber der GPU wirken aber allgemein.

Also Input (Mouse)=>CPU=>Renderqueue=>GPU=>Monitor! Dabei zeichnet Nvidia besonders niedrige Werte, wenn die Hardware RLA kompatibel ist (und muss es auch sein), sonst könnte sogar AMDs Variante Vorteile bieten. Das Texturing spielt dabei keine wesentliche Rolle, die Berechnungszeit verkürzt sich jedoch wenn die Bildrate steigt.

Die gemessenen Werte gelten also für das Testsystem im getesteten Spiel Overwatch und nicht allgemein, daher sind allgemeine Fazit auch nicht aussagekräftig. Ich vermute mal daher stellt man die Messreihen mit explizieter Erläuterung erst gar nicht online. Fazit ist eher, eine höhere CPU Leistung und Threadoptimierung kann Techniken wie Reflex und Antilag beschleunigen. Das AMD da einige Nachteile im CPU Limit unter DX11 hat, ist bekannt. Trotzdem wird es immer wieder getestet. Warum auch immer...

Das heißt also letztlich, ich kann die Pipeline aus Eingabe=>Berechnung=>Befehl=>Bild=>Visuelle Ausgabe schon bei der Eingabe abschießen (und das liegt auch daran wie schnell "ich selbst" jeweils "klicke"=>ergo spielt der, der vor dem Bildschirm sitzt auch noch eine wesentliche Rolle). Da kann die GPU mal gar nichts dafür und auch kein Hersteller. Zumal per Engine auch gerne auf Hardware optimiert wird (UE4 unter DX11), darauf hat ein CPU oder GPU Hersteller nur unwesentlichen Einfluss, sondern wählen Entwickler die Variante die am Besten zum gewollten Ergebnis passt. Das alles per Treiber zu "cheaten" ist faktisch unmöglich und ist unter DX12 auch nicht mehr erwünscht.

Ich müsste also für auswertbare Messreihen garantieren, dass ich immer gleiche Eingabezeiten erreiche bzw. auf den Bildinhalt immer gleichschnell reagiere, wie nur? Das Ganze setzt sich für alle Stufen in der Pipeline fort, sowie Hintergrundprozesse usw..

Danke für dem Beitrag!

Bitte zuerst dem Artikel bzgl LDAT lesen!

Ich messe mit LDAT alles nicht nur die GPU…

Sorry wenn ich es jetzt mal drastisch und direkt formulieren muss: Wer lesen kann ist klar im Vorteil…
 
Um so schlimmer.

Sorry, dass es ich jetzt dramatisch schreibe, aber ich halte von den Ergebnissen nicht viel. Viel wichtiger für deine Messreihen sind dann die Taktverläufe der CPU und an welchen USB Port der LDAT hängt. Das die Renderqueue dann eine wesentliche Rolle dabei spielt habe ich bereits geschrieben. Ein Framelimiter wird dann immer bessere Latenzen liefern, aber wo ist das Problem wenn ich den im AMD Treiber aktivieren könnte, aber nicht mache? Die Karte aber rennen lasse?

Immer dann wenn man mit LDAT misst und die CPU + Renderqueue leicht unter dem GPU Limit liefert, zeichnet LDAT wunderbare Latenzen. Mal Gedanken darüber machen und warum! Nvidia scriptet die Renderqueue also per Treiber oder gleich über Reflex SDK. Sie tauschen sie also sozusagen gegen eine GPU kompatible dynamische Variante, soweit es nicht vom Entwickler berücksichtig wird und liefern dazu auch noch gleich das Equipment für Tester.

Ich brauch den Artikel zu LDAT nicht zu lesen und stellt mich hier nicht immer hin, als wäre ich ein "Anfänger".

Das alles steht schon in meinen ersten Beitrag, du scheinst es aber ignorieren zu wollen. Mehr Hinweise kann man nicht geben, tut mir Leid!
 
Zuletzt bearbeitet von einem Moderator :
Um so schlimmer.

Sorry, dass es ich jetzt dramatisch schreibe, aber ich halte von den Ergebnissen nicht viel. Viel wichtiger für deine Messreihen sind dann die Taktverläufe der CPU und an welchen USB Port der LDAT hängt. Das die Renderqueue dann eine wesentliche Rolle dabei spielt habe ich bereits geschrieben. Ein Framelimiter wird dann immer bessere Latenzen liefern, aber wo ist das Problem wenn ich den im AMD Treiber aktivieren könnte, aber nicht mache? Die Karte aber rennen lasse?

Immer dann wenn man mit LDAT misst und die CPU + Renderqueue leicht unter dem GPU Limit liefert, zeichnet LDAT wunderbare Latenzen. Mal Gedanken darüber machen und warum! Nvidia scriptet die Renderqueue also per Treiber oder gleich über Reflex SDK. Sie tauschen sie also sozusagen gegen eine GPU kompatible dynamische Variante, soweit es nicht vom Entwickler berücksichtig wird und liefern dazu auch noch gleich das Equipment für Tester.

Ich brauch den Artikel zu LDAT nicht zu lesen und stellt mich hier nicht immer hin, als wäre ich ein "Anfänger".

Das alles steht schon in meinen ersten Beitrag, du scheinst es aber ignorieren zu wollen. Mehr Hinweise kann man nicht geben, tut mir Leid!

Ich wiederhole mich, lies die Artikel zu LDAT und vor allem die anderen von mir zum Thema Reflex und IGFL

Besonders: MSA zu LDAT
 
Ich muss mich da auch mal mit einklinken. Wir haben mit Absicht eher langsame Grafikkarten gewählt, um die CPU als extremen Faktor etwas abzumildern zu können. Da spielte sicher auch die MSA zu LDAT eine Rolle. Die Maus sollte im geeigneten USB 3 Port stecken, das läuft dann eh direkt über die CPU und nicht das Chipset.

Zu AMDs "Frame-Limiter" schreibe ich jetzt mal bewusst nichts im Detail, aber ich kenne niemanden, der den in solchen Spielen nutzen würde. AMDs Frame Rate Target Control (FRTC) steckt in AMDs Chill und ist eher eine Art Range-Limiter, aber kein echter Frame-Limiter im eigentlichen Sinne wie bei NVIDIA. Da steigen die Latenzen mit etwas Pech eher an, als dass sie sinken und die Karte macht meist unvorhersehbare Dinge. Und es wären wieder Äpfel mit Birnen im Vergleich, weil das keiner exakten MSA standhält und bei jedem Run stark abweichende Ergebnisse liefern würde.

Ein In-Game-Limiter ist noch akzeptabel, alles andere von außen aus meiner Sicht eher weniger. Die Gründe sind ja allgemein bekannt.

Edit:
Chill greift sehr stark in den Arbitrator ein, auch was die Power Estimation und die Vorhersage betrifft. Ich habe damals, als Chill aufkam, lange getestet und das Ganze für FP-Shooter als einigermaßen unbrauchbar wieder abgehakt. Der Artikel heute hinterfragt das Zusammenspiel von Grafikhardware und Treiber und beurteilt am Ende auch die Wirksamkeit der vier verschiedenen Technologien und dem, was zwischen dem Klick und dem Pixel am Monitor passiert.

Es ist, bis auf die Grafikkarte, immer die selbe Hardware und LDAT macht nichts anderes, außer den mechanischen Klick abzufangen und den resultierenden Pixel auf dem Bildschirm dazu auszuwerten. Da ist es egal, wer der Hersteller ist, denn AMD hätte das genauso gebaut. Die Systemlatenz ist nun einmal die Summe aus Hard- und SOFTware. Und da müssen die GPU und die Treiber samt Features die Hosen runterlassen. Wie soll man es denn sonst bitte schön testen? Plausibilitätstests mit einer Highspeed-Cam ergeben doch nichts anderes. Den Spieler interessieren doch nur die Latenzen zwischen seiner physikalischen Klickerei und dem ins Auge springenden Pixel.

Diese ganzen Treiber-Features sollen doch dazu dienen, auch diese Latenzen zu verringern. Ein Use-Case, wo kaum welche auftreten, ist da nicht hilfreich, weil man dann auch diese Treiber-Features nicht mehr braucht. Die Wirksamkeit eine Kompressionsverbandes teste ich doch auch nicht mit einem kleinen Blutstropfen. Overwatch ist in gewisser Weise Worst-Case und AMD bewirbt ja seine Features auch mit diesen Spielen. Dann nimmt man es eben auch :)
 
Zuletzt bearbeitet :
Dem ist soweit nichts mehr hinzuzufügen…

Weitere Spiele folgen

Edit:

DX11, DX12 eventuell Vulkan
 
Zuletzt bearbeitet :
Ich muss mich da auch mal mit einklinken. Wir haben mit Absicht eher langsame Grafikkarten gewählt, um die CPU als extremen Faktor etwas abzumildern zu können. Da spielte sicher auch die MSA zu LDAT eine Rolle. Die Maus sollte im geeigneten USB 3 Port stecken, das läuft dann eh direkt über die CPU und nicht das Chipset.

Zu AMDs "Frame-Limiter" schreibe ich jetzt mal bewusst nichts im Detail, aber ich kenne niemanden, der den in solchen Spielen nutzen würde. AMDs Frame Rate Target Control (FRTC) steckt in AMDs Chill und ist eher eine Art Range-Limiter, aber kein echter Frame-Limiter im eigentlichen Sinne wie bei NVIDIA. Da steigen die Latenzen mit etwas Pech eher an, als dass sie sinken und die Karte macht meist unvorhersehbare Dinge. Und es wären wieder Äpfel mit Birnen im Vergleich, weil das keiner exakten MSA standhält und bei jedem Run stark abweichende Ergebnisse liefern würde.

Ein In-Game-Limiter ist noch akzeptabel, alles andere von außen aus meiner Sicht eher weniger. Die Gründe sind ja allgemein bekannt.

Edit:
Chill greift sehr stark in den Arbitrator ein, auch was die Power Estimation und die Vorhersage betrifft. Ich habe damals, als Chill aufkam, lange getestet und das Ganze für FP-Shooter als einigermaßen unbrauchbar wieder abgehakt. Der Artikel heute hinterfragt das Zusammenspiel von Grafikhardware und Treiber und beurteilt am Ende auch die Wirksamkeit der vier verschiedenen Technologien und dem, was zwischen dem Klick und dem Pixel am Monitor passiert.

Es ist, bis auf die Grafikkarte, immer die selbe Hardware und LDAT macht nichts anderes, außer den mechanischen Klick abzufangen und den resultierenden Pixel auf dem Bildschirm dazu auszuwerten. Da ist es egal, wer der Hersteller ist, denn AMD hätte das genauso gebaut. Die Systemlatenz ist nun einmal die Summe aus Hard- und SOFTware. Und da müssen die GPU und die Treiber samt Features die Hosen runterlassen. Wie soll man es denn sonst bitte schön testen? Plausibilitätstests mit einer Highspeed-Cam ergeben doch nichts anderes. Den Spieler interessieren doch nur die Latenzen zwischen seiner physikalischen Klickerei und dem ins Auge springenden Pixel.

Diese ganzen Treiber-Features sollen doch dazu dienen, auch diese Latenzen zu verringern. Ein Use-Case, wo kaum welche auftreten, ist da nicht hilfreich, weil man dann auch diese Treiber-Features nicht mehr braucht. Die Wirksamkeit eine Kompressionsverbandes teste ich doch auch nicht mit einem kleinen Blutstropfen. Overwatch ist in gewisser Weise Worst-Case und AMD bewirbt ja seine Features auch mit diesen Spielen. Dann nimmt man es eben auch :)
AMDs FTRC ist auch auch kein FrameLIMIT, es ist schlicht eine Zielvorgabe (Target) und die macht, gerade mit FreeSync, einen sehr guten Job. Da FRTC möglichst Sync (auch Imput!) bleiben will werden einige Frames (je nach Monitor) auch mal "künstlich" verzögert, in der Summe sollte die Latenz ~ niedriger als ein hartes Limit sein.

Chill ist dann sinnvoll wenn es immer wieder mal böse minFPS Abschnitte im Spiel gibt, dann lieber mit Chill min und max anpassen, als ein hartes Limit auf die minFPS.

EDIT
Und ntürlich bedeuten mehr FPS idR auch niedrigere Latenzen.
Würdest du im GPU Limit bei BEIDEN eine stärkere GPU verwenden (mehr FPS), dann würden beide auch bessere Latenzen Zeigen (bis die GPUs so schnell wären, dass es keinen unterschied mehr machen würde). Du vergleichst hier aber eben nicht nur die verschiedenen GPUs, sondern auch verschiedene Software, nvidia reflex. Du änderst damit also nicht nur die GPUs, sondern auch den "Benchmark".
 
Zuletzt bearbeitet :
AMDs FTRC ist auch auch kein FrameLIMIT, es ist schlicht eine Zielvorgabe (Target) und die macht, gerade mit FreeSync, einen sehr guten Job. Da FRTC möglichst Sync (auch Imput!) bleiben will werden einige Frames (je nach Monitor) auch mal "künstlich" verzögert, in der Summe sollte die Latenz ~ niedriger als ein hartes Limit sein.

Chill ist dann sinnvoll wenn es immer wieder mal böse minFPS Abschnitte im Spiel gibt, dann lieber mit Chill min und max anpassen, als ein hartes Limit auf die minFPS.

EDIT
Und ntürlich bedeuten mehr FPS idR auch niedrigere Latenzen.
Würdest du im GPU Limit bei BEIDEN eine stärkere GPU verwenden (mehr FPS), dann würden beide auch bessere Latenzen Zeigen (bis die GPUs so schnell wären, dass es keinen unterschied mehr machen würde). Du vergleichst hier aber eben nicht nur die verschiedenen GPUs, sondern auch verschiedene Software, nvidia reflex. Du änderst damit also nicht nur die GPUs, sondern auch den "Benchmark".

Nein, die Bedingungen (Benchmark) sind gleich!

Es werden die Gimmicks zur Latenzreduzierung beider Hersteller unter den gleichen Bedingungen verglichen.

Das AMD und Nvidia hier unterschiedliche Möglichkeiten nutzen, dafür kann ich nichts. Letztlich schaffen es beide im Spiel Overwatch auf ein ähnliches Niveau zukommen.

Nvidia hat hier bezogen auf die Stabilität und der Tatsache, dass es auch statistisch funktioniert, ganz einfach die Nase ein kleines Stück weiter vorn!

Sollte ich damit die Gefühle einiger AMD Fan-Boys verletzt haben, ist das nicht mein Problem. Zahlen, Daten und Fakten sind mit Gefühlen nicht änderbar.

AMD bewirbt Radeon Boost mit dem Titel: Ultimatives Latenzverbessungs-Gimmick…

Grundsätzlich nicht falsch, aber eben auch nicht wirklich ultimativ!
 
Ich muss sagen, dass ich von dieser Thematik nicht all zu viel verstehe, es aber auf meine Interessensliste (ähnliche Ansicht wie @ipat66 ) auch nicht wirklich weit oben steht.

ABER wenn man doch hier ein solch sachliches und ausformuliertes Feedback bekommt, auch (oder gerade) wenn dieses auch einmal kritisch ist, empfinde ich die Antworten von @FritzHunter01 schon eher pampisch - das sollte alle, die an dieser tollen Seite und Community mitwirken, doch mit gutem Beispiel voran gehen.
 
AMD bewirbt Radeon Boost mit dem Titel: Ultimatives Latenzverbessungs-Gimmick…
... und es funktioniert vor allem nur bei Overwatch. Soll man jetzt Spiele nehmen, wo es erst gar nichts bringt? Das wiederum wäre dann allgemeingültiger? Es war schon schwer, für Radeon Boost überhaupt einen guten use-case zu finden :D

Das Problem ist eher:
Wie biased ist ein Post? Unter DX12 bekommt übrigens NV eins auf den Deckel, unter DX11 ist Radeon Boost eher ein Totalausfall. Ich erinnere mich aber, hier bereits die Ankündigungend es Follow-Ups gelsen zu haben. Das sollte man schon abwarten, bevor man einem Autor Inkompetenz unterstellt.
 
Zuletzt bearbeitet :
Radeon Boost und Radeon Anti-Lag müssen nicht in das Spiel integriert werden, reflex von nvida aber sehr wohl.


Was AMD WIKLICH zu Boost schreibt:

Turbocharge Your Game​

AMD Radeon™ Boost dynamically lowers resolution of the entire frame when fast on-screen character motion is detected via user input, allowing for higher FPS with little perceived impact to quality.2 Originally supporting select DirectX® 11 games,

this feature now takes advantage of the variable rate shading hardware found on the Radeon™ RX 6000 series graphics cards and supported DirectX® 12 titles delivering extra performance and increased responsiveness while you play.

Also "increased responsiveness" mit DX12, nicht zwangsläufig mit DX11.
 
Uff Igor, da habt Ihr ja was angezettelt hier...Weiß gar nicht wo ich hier anfangen soll.

Erstmal muss ich @Igor korrigieren, es gibt sowohl Chill als auch einen eigenen Framelimiter im AMD Treiber seit geraumer Zeit wieder(noch nicht all zu lange,ich meine seit etwa 2-3 Treiberversionen wieder),vorher musste man min/max einfach gleich setzten, dass haben aber tatsächlich viele nicht geschnallt und ich hab nicht geschnallt das AMD das dermaßen bescheuert geregelt hat. Naja, Fakt ist,ein Framelimiter via Treiber ist vorhanden.Screenshot (755).png

Ich stimme Gastello in einigen Punkten bei seiner Ausführung zu und mit Verlaub @FritzHunter01 er ist alles nur kein "AMD Fanboy"
Davon ab,finde ich es absolut unangemessen, als Autor bereits im Artikel wie auch hier dann im Thread mit einem solchen "Kampfbegriff" inflationär zu wuchern. Da bringt dann auch der charmante Wortwitz an einigen Stellen im Artikel keine Besserung mehr,wenn man in eben diesem quasi direkt vermeintliche Kritik/Argumente/Feedback damit stigmatisiert.

In fast jedem Forum ist der Begriff perse ein Grund für eine Sperrung/Verwarnung,das haut man doch nicht so in einen Artikel!

Zu Radeon Boost: Mit dem Thema Latenzen kenne ich mich recht wenig aus, nach meiner Erfahrung funzt Boost aber unter DX12 wesentlich besser,warum auch immer. Generell bin ich der Auffassung das Boost weniger eine Latenzreduktion bringen soll sondern eigentlich primär flüssige Bildraten in Bewegung gewährleisten soll,vor allem auf schwächeren Systemen.Die Latenz ist da natürlich ein willkommener Nebeneffekt. Dieses Prinzip funktioniert mit Boost bei mir in Cyberpunk z.B. überraschend gut,kappt mir aber in Borderlands die maximale Framerate.Warum auch immer.

@summit Doch Boost muss integriert werden,egal ob auf DX11 oder DX12 Basis!
 
Zuletzt bearbeitet :
Radeon Boost und Radeon Anti-Lag müssen nicht in das Spiel integriert werden, reflex von nvida aber sehr wohl.


Was AMD WIKLICH zu Boost schreibt:

Also "increased responsiveness" mit DX12, nicht zwangsläufig mit DX11.

Sorry, aber stimmt so nicht!


NULL und Anti-Lag funktioniert über den Treiber… bringt aber nicht wirklich viel zumindest in DX11… Nvidia NULL sowieso nur in DX11 möglich

Ein IGFL ist da besser!
 
Sorry, aber stimmt so nicht!


NULL und Anti-Lag funktioniert über den Treiber… bringt aber nicht wirklich viel zumindest in DX11… Nvidia NULL sowieso nur in DX11 möglich

Ein IGFL ist da besser!
Nein, Boost muss nicht in die Engine integriert werden es muss lediglich im Treiber unterstützt werden(Homebrew!).
Glaubt mir doch bitte endlich mal.

Ein iGFL schließt AntiLag nicht aus. ;)
 
Geht wieder heiß her. Mir erschließt sich der Nutzen des Ganzen nicht wirklich. Kann gut sein, dass beide Hersteller mit ihren Technologien da irgendwas optimieren, was dann dafür sorgt, dass ich als auf der Lauer liegender Sniper einen vorbeibuschenden Gegner besser treffe, weil mein Lag kleiner ist.
Das scheint mir in der "static" Messung vor allem der Fall und korreliert mit den Ergebnissen des LT-Videos. Trotzdem bin ich irgendwie auch bei denen, die ja noch ne Maus klicken, die am Mainboard hängt, dass die CPU anspricht, die das entsprechende Rendering veranlasst, was die GPU errechnet und via DP und Einmeterfünfzig Kabel an den Monitor ausgibt.
Diese Vergleichbarkeit kann man nicht herstellen, vor allem nicht online, denn da kommt ja noch das Internet dazwischen. Insofern ist es eine Optimierungsmöglichkeit für das eigene System, ob das Ganze positive Auswirkungen in kompetitiven Titeln hat, kann ich anhand dessen nicht beurteilen. Und wie sich dazu G-Sync oder FreeSync verhalten ebenfalls nicht.
Ist ne Menge Aufwand, die Ergebnisse sind auch wirklich aufschlussreich. Relevanz hat das auch für mich nicht.
 
Oben Unten