Nachteile von FreeSync LFC gegenüber G-Sync

[webmi]

Wahrscheinlich habe ich mal wieder eine viel zu simpel gestrickte Vorstellung von der Sache.
In meiner Vorstellung arbeitet der Monitor nach einem festen Zeitplan um sich Bilder von der GraKa abzuholen.
Aber die GraKa sagt entweder: ‚Kann grad nich‘ oder aber liefert zur falschen Zeit, und jetzt sagt der Moni: ‚Pech gehabt, nimm den nächsten Zug‘.
Für mich ist der Monitor der „Saubermann“, er kommt termingerecht, pflichtbewusst und vorhersehbar 60 bis 144 mal in der Sekunde seiner Aufgabe nach.
Die GraKa ist der Rüpel, der mit der Summe seiner Gebrechen unabgesprochen was ins Signalkabel wirft.
Um der GraKa nun entgegen zu kommen, sagt der Monitor: ‚Nun gut, ich baue mir da mal einen kleinen Horchposten ein, der mir verrät, ob Du gelegentlich mal wieder was Gefälliges zusammengeschustert hast.
Der Moni ist nunmehr nicht mehr wie die Bahn (höhö) nach Plan unterwegs, sondern wie ein Taxi nach Kundenwunsch.
Man mag vom Hersteller erwarten, dass er hier ein gutes Teil verbaut oder was taugliches progammiert, denn er lässt es sich ja auch gut bezahlen, aber letztlich dient es dazu die Zickereien der GraKa ausbügeln. Also würde ich weiterhin eher auf die schnaufende GPU, als denn den eleganten Taktzeiger (extra tendenziös formuliert) im Moni tippen, wenns mal nicht so schwuppt.

prinzipell schöner vergleich. die gpu würde jedes mal, wenn ein zug voll ist, einen lossenden. das würde den bahnhof des monitors aber überfluten bzw totales chaos im bahnhof monitor verursachen (-> tearing), solange nicht alle leute ausgestiegen sind. deshalb sagt jetzt der bahnhof des monitors zum bahnhof der gpu, weiter bitte, nächster zug, der hier ist leer, ich kann wieder einen vollen aufnehmen und erst dann fährt der nächste zug los.

ohne einen bahnhof in der gpu, der züge voll macht und dann auf warteposition hält um dann mit dem bahnhof des monitors zu kommunizieren, funktioniert adaptive sync nicht. also nein, es ist nicht alleine ein monitor thema, sondern eben auch eines der gpu. (nicht alle amd karte zb. supporten free-sync).

 

[fullHDade]

Ja, ja, webmi, das ist doch auch meine Kerbe: Der Moni-Bahnhof öffnet und schließt nach „Plan“ (von wo dieser auch immer ausgegeben wurde).
Und der verspätete Zug aus der GraKa fährt regelmäßig gegen das gerade geschlossene Bahnhofstor (und verpufft ins Datennirwana).

 

[Brainorg]

Die Zeiten, die für die Berechnung eines Bildes gebraucht werden, können stark variieren. Das führt bei eingeschaltetem V-Sync dazu, dass der Bildfluss ruckelt, wenn nicht ständig mehr als die meist üblichen 60 Bilder pro Sekunde von der Grafikkarte geliefert werden. Auch können Bilder verloren gehen, wenn sie besonders schnell berechnet wurden, das Display aber noch wartet, bis die nächste Sechzigstelsekunde vergangen ist. Das führt, beispielsweise bei Rennspielen trotz konstant angezeigter 60 fps manchmal zu einer nicht ganz flüssigen Darstellung. Es lässt sich mit mehrfachen Puffern lindern, erhöht aber die Eingabelatenz.
Das kann aber zu einem Zerreißen des Bildes führen, auch Tearing genannt, wenn während der Darstellung eines Bildes schon das folgende aufgebaut wird. Sowohl G-Sync als auch Adaptive Sync gehen ganz anders vor: Es gibt keine feste Frequenz mehr, in der die GPU ein neues Bild liefern muss. Vielmehr bleibt der Bildinhalt stehen, bis der nächste Frame fertig ist. Die Grafikkarte selbst fordert dann eine Aktualisierung auf dem Display an. Dadurch gehen keine Bilder mehr verloren, und auch nur fertige ganze Bilder werden ohne Tearing dargestellt.
Hierzu muss aber der Monitor die entsprechenden Scaler verbaut haben bzw. um einen größeren Bereich abzudecken auf LFC unterstützen.

Soll heißen letztendlich ist es egal WER bzw. WELCHE Komponente das Problem verursacht. Gelöst wird es zum größten Teil durch funktionen der Sacler die im Monitor verbaut sind, weshalb im obigen Test auch logischerweise Monitore betrachtet wurden und keine Grafikkarten.

 

[webmi]

Ja, ja, webmi, das ist doch auch meine Kerbe: Der Moni-Bahnhof öffnet und schließt nach „Plan“ (von wo dieser auch immer ausgegeben wurde).
Und der verspätete Zug aus der GraKa fährt regelmäßig gegen das gerade geschlossene Bahnhofstor (und verpufft ins Datennirwana).

habs überarbeitet, aus der sicht richtig, der bahnhof gpu ist das problem in dieser ansicht. in meiner ansicht wäre der bahnhof monitor das problem, weil er zu langsam arbeitet

Gelöst wird es zum größten Teil durch funktionen der Sacler die im Monitor verbaut sind, weshalb im obigen Test auch logischerweise Monitore betrachtet wurden und keine Grafikkarten.

@brain, eben nicht vom monitor alleine, aber ist recht, mittlerweile haben wir durch eine gute metapher alle kapiert, das sowohl bahnhof gpu als auch bahnhof monitor mitspielen müssen. dir gehts, so wie mir, jetzt nur noch ums recht haben. soll jeder anhand der sehr guten veranschaulichung von fullHDade selbst entscheiden. letztendich auch völlig egal, in welchem unterforum das ganze nun hängt. viel wichtiger ist das man kapiert, wie es funktioniert.

 

[DaDare]

Hier mal ein Paper zu Adative Sync. Interessant ist für den Fall hier die Seite 3.
http://www.vesa.org/wp-content/uploads/2014/07/VESA-Adaptive-Sync-Whitepaper-140620.pdf

Gibt es einen Bericht, der sich genauer mit dem G-Sync Modul auseinander gesetzt hat? Sprich wie genau es funktioniert? Und bitte keine Artikel posten, die Aussagen Nvidias als Quelle verwendet haben.

 

[Brainorg]

Funktionsweise Gsync/Freesync:
Ist es nicht eher so, dass der Graka-Bahnhof dem Monitor-Bahnhof sagt, du machst jetzt die Schranke auf, ich schicke dir den nächsten Zug.
Der Grafikkartenbahnhof ist der Taktgeber und der Monitor-Bahnhof passt sich an diesen Takt an.

Der Moni-Bahnhof öffnet und schließt nach „Plan“ (von wo dieser auch immer ausgegeben wurde).
Und der verspätete Zug aus der GraKa fährt regelmäßig gegen das gerade geschlossene Bahnhofstor (und verpufft ins Datennirwana).

Das wäre VSync bzw. das ist das was Vsync "verbessert". Hier wartet der Grakabahnhof auf den Monitor-Bahnhof und das produziert inputlag. Deshalb sind ja auch die neuen Sync-Verfahren "besser".

 

[webmi]

Ist es nicht eher so, dass der Graka-Bahnhof dem Monitor-Bahnhof sagt, du machst jetzt die Schranke auf, ich schicke dir den nächsten Zug.
Der Grafikkartenbahnhof ist der Taktgeber und der Monitor-Bahnhof passt sich an diesen Takt an.

nope. nach diesem prinzip funktioniert non-sync. deshalb entsteht tearing. die leute aus dem einen zug steigen am bahnhof monitor noch aus (bild wird grad noch vom monitor ausgegeben) während der nächste volle zug (nächstes bild der gpu) reindonnert und dort ebenfalls leute aussteigen (auch dieses bild nun ausgegeben wird) -> ausgabe überschneidet sich -> tearing

 

[Brainorg]

nope. nach diesem prinzip funktioniert non-sync. deshalb entsteht tearing. die leute aus dem einen zug steigen am bahnhof monitor noch aus (bild wird grad noch vom monitor ausgegeben) während der nächste volle zug (nächstes bild der gpu) reindonnert und dort ebenfalls leute aussteigen (auch dieses bild nun ausgegeben wird) -> ausgabe überschneidet sich -> tearing

Nein das hast du falsch verstanden. Meine von dir zitierte Beschreibung, zeigt die G-bzw. Freesync Funktionsweise auf.
Weshalb Tearing entsteht, sollte klar sein. Aber dennoch gut beschrieben.

 

[webmi]

mit adaptive sync ist nicht mehr die gpu der taktgeber, das entspräche non-sync. er hält sich auch nciht an einen vereinbarten fahrplan, das wäre v-sync. sondern der monitor gibt jetzt den takt an, weil er bestimmt wann der nächste zug aus dem bahnhof gpu losfährt, indirekt.

das war auch der denkfehler, den ich hatte, als ich die metapher von full das erste mal gelesen habe, ohne sie genau verstanden zu haben.

 

[Brainorg]

mit adaptive sync ist nicht mehr die gpu der taktgeber, das entspräche non-sync. er hält sich auch nciht an einen vereinbarten fahrplan, das wäre v-sync. sondern der monitor gibt jetzt den takt an, weil er bestimmt wann der nächste zug aus dem bahnhof gpu losfährt, indirekt.

das war auch der denkfehler, den ich hatte, als ich die metapher von full das erste mal gelesen habe, ohne sie genau verstanden zu haben.

Nein eben nicht
F-/Gsync:
Die Graka gibt dem Monitor nun vor, "so, du zeigst jetzt mein nächstes, vollständiges Bild an".
Genau aus dem Grund wird auch die Hz-Zahl des Monitors variabel, da sie sich an die Bildfrequenz der Graka anpasst.
In der Praxis bedeutet das: die Grafikkarte stellt einen Frame fertig, danach sendet sie das Bild an den Monitor und teilt zugleich mit, dass es dargestellt werden kann. Erst auf diesen Befehl hin leitet der Monitor einen Refresh-Zyklus ein. Danach pausiert das Panel und wartet, bis das nächste Frame von der Grafikkarte kommt – und erst dann findet der nächste Refresh statt.

Wenn der Monitor der Taktgeber ist, wäre das VSync, da hier die Graka auf den Monitor wartet, weshalb auch der inputlag steigt. Das sieht man ja schon daran, das bei Vsync die FPS nicht höher als die Hz-Zahl des Monitors geht, da dieser ja der Taktgeber ist.

dir gehts, so wie mir, jetzt nur noch ums recht haben. soll jeder anhand der sehr guten veranschaulichung von fullHDade selbst entscheiden.

Auch hier muss ich dir leider widersprechen. Mir geht es mit nichten ums "recht haben".
Mal abgesehen davon geht das auch nicht, den die Technik funktioniert, wie sie eben funktioniert.
Und bezüglich der Technik, haben wir eigtl. beide immer das selbe behauptet mMn.
Mir geht es anhand des aufzeigens nur darum, dass dieser Thread bzw. der obige Test, sehr wohl ein reiner Monitorfall ist, denn es wird die Technik betrachtet, die dem Tearing entgegen wirkt und nicht die Technik, die eigtl. dafür verantwortlich ist, dass es Tearing gibt.
Und letztendlich, um mal wieder BTT zu kommen , war ja die Kernaussage, das im Moment Freesync + FLC immer noch leichte Nachteile gegenüber G-Sync hat.

 

[fullHDade]

@brainorg:
Gut, habe ich nun verstanden.
Die GraKa liefert nicht unbedingt und ausschließlich zu spät, sondern kann es im Gegenteil zuweilen garnicht abwarten was Neues abzubieten.
Stellt sich nun die Frage, wer –GraKa oder Monitor- das Bild solange „aufhebt“, bis es in den Takt passt.
Jetzt muss ich mir wohl einen Argumentationsstrohhalm suchen, um mein Konstrukt „Böse GraKa, guter Moni“-Welt irgendwie zu retten.

Ah!
Ablenkung hilft immer.

Öehm, was ist ein Scaler?

Außerdem geht mir das hier zu schnell, ich kriege gerade mal ein Post fertig, während drei Texte von Euch hier reinkommen….

 

[webmi]

Nein eben nicht
F-/Gsync:
Die Graka gibt dem Monitor nun vor, "so, du zeigst jetzt mein nächstes, vollständiges Bild an".
Genau aus dem Grund wird auch die Hz-Zahl des Monitors variabel, da sie sich an die Bildfrequenz der Graka anpasst.

wenn das wirklich so wäre und die gpu dem monitor sagen würde, jetzt ist es soweit, gib sofort das nächste aus, egal ob du mit dem letzten fertig bist oder nicht... überleg doch mal was dann passieren würde -> tearing unter umständen

der moni erkennt wann das bild fertig ausgegeben wurde und fordert erst dann das nächste an. das automatische und logische resultat ist, das sich die hz des monitors an die fps anpassen.

Mir geht es anhand des aufzeigens nur darum, dass dieser Thread bzw. der obige Test, sehr wohl ein reiner Monitorfall ist, denn es wird die Technik betrachtet, die dem Tearing entgegen wirkt und nicht die Technik, die eigtl. dafür verantwortlich ist, dass es Tearing gibt.

sag mal steht du auf einem schlauch oder so?! die technik, die gegen tearing wirkt, besteht aus dem zusammenspiel und der kommunikation zwischen monitor und GPU... das thema adaptive sync ist sowohl im monitor bereich als auch im gpu bereich zu suchen. nun hast du es hier gepostet, wenn interessiert das eigtl?! mich nicht.

BTT, freesync hat gegenüber gsync auch vorteile, denn es ist zumindest in der theorie schneller. es muss nicht wie gsync ständig abfragen, ob das bild schon fertig ausgegeben wurde -> weniger latenz (wie gesagt, zumindest in der theorie aufgrund seiner funktionsweise)

FreeSync, as AMD pointed out, does not utilize any polling system. The DisplayPort Adaptive-Sync protocols allow the system to send the signal to refresh at any time, meaning there is no need to check if the display is mid-scan. The nice thing about this is that there’s no performance overhead and the process is simpler and more streamlined.

quelle

 

[Brainorg]

wenn das wirklich so wäre und die gpu dem monitor sagen würde, jetzt ist es soweit, gib sofort das nächste aus, egal ob du mit dem letzten fertig bist oder nicht... überleg doch mal was dann passieren würde -> tearing unter umständen

der moni erkennt wann das bild fertig ausgegeben wurde und fordert erst dann das nächste an. das automatische und logische resultat ist, das sich die hz des monitors an die fps anpassen.

sag mal steht du auf einem schlauch oder so?! die technik, die gegen tearing wirkt, besteht aus dem zusammenspiel und der kommunikation zwischen monitor und GPU... das thema adaptive sync ist sowohl im monitor bereich als auch im gpu bereich zu suchen. nun hast du es hier gepostet, wenn interessiert das eigtl?! mich nicht.

BBT, freesync hat gegenüber gsync auch vorteile, denn es ist zumindest in der theorie schneller. es muss nicht wie gsync ständig abfragen, ob das bild schon fertig ausgegeben wurde -> weniger latenz (wie gesagt, zumindest in der theorie)

Nochmal für webmi:

Wird V-Sync aktiviert, stellt die Grafikkarte dem Monitor ein fertiges Bild immer dann zur Verfügung, wenn er ein neues Bild darstellen muss. Bei einem 60-Hz-Monitor liefert die Grafikkarte also maximal 60 Bilder pro Sekunde. Alle 16 Millisekunden genau ein Bild, das der Monitor daraufhin vollständig darstellt. Braucht die Grafikkarte weniger als 16 Millisekunden für das nächste Bild, hält sie es so lange zurück, bis der Monitor wieder bereit ist. Braucht sie länger, stellt der Monitor das letzte Bild noch einmal dar. Das fertige Bild wird einen Zyklus später ausgegeben. Sollte die Grafikkarte bis dahin ein neues erstellt haben, verfällt es. Wird V-Sync deaktiviert, gibt es keine Synchronisation zwischen der Bildwiederholfrequenz des Bildschirms und der Auslieferung der Bilder durch die Grafikkarte mehr. Die Grafikkarte erstellt Bilder, so schnell sie kann. Sobald ein neues Bild fertig ist, geht es an den Monitor. Ist der gerade dabei, den Bildschirminhalt mit einem Bild zu erneuern und erhält er währenddessen das nächste Bild, stellt er dieses noch im selben Aktualisierungsvorgang dar. Ohne V-Sync können so innerhalb einer Aktualisierung des Bildschirms mehrere Teilbilder gleichzeitig auf den Monitor gezeichnet werden.

Nvidias G-Sync soll wie aktiviertes V-Sync „Tearing“ verhindern, ohne den Input Lag durch das Verzögern oder mehrfache Darstellen von Bildern zu erhöhen.

Der Trick: G-Sync-Monitore arbeiten nicht mehr mit einer festen, sondern mit einer variablen Bildwiederholfrequenz, die sich nach der Grafikkarte richtet: wenn die Grafikkarte 50 Bilder pro Sekunde liefert, läuft der Monitor mit 50 Hertz. Sind es 40 FPS, liegen beim Display 40 Hz an.
In der Praxis bedeutet das: die Grafikkarte stellt einen Frame fertig, danach sendet sie das Bild an den Monitor und teilt zugleich mit, dass es dargestellt werden kann. Erst auf diesen Befehl hin leitet der Monitor einen Refresh-Zyklus ein. Danach pausiert das Panel und wartet, bis das nächste Frame von der Grafikkarte kommt – und erst dann findet der nächste Refresh statt.

Tearing durch das gleichzeitige Darstellen mehrerer Bilder in einem Refresh-Zyklus und Stottern durch das Aufschieben von Bildern werden durch G-Sync effektiv verhindert. Auch der Input-Lag sinkt. Allerdings ist er höher als bei abgeschaltetem V-Sync, da die Frames nicht immer sofort nach der Fertigstellung dargestellt werden können. Denn ist der Monitor gerade noch damit beschäftigt, den letzten Frame zu zeichnen, lässt er die Ausgabe eines weiteren nicht zu – andernfalls würden sich Konditionen wie bei V-Sync aus einstellen, inklusive Tearing.
G-Sync funktioniert nicht unterhalb von 30 FPS. Liegt die Geschwindigkeit oberhalb der Bildwiederholfrequenz des Monitors, arbeitet G-Sync identisch zu V-Sync.
Die untere Grenze ist eine manuell gesetzte. Würde G-Sync auch unterhalb funktionieren, würde der Monitor in Szenen, in denen weniger als 30 Bilder pro Sekunde berechnet werden, seltener als 30 Mal pro Sekunde den Bildschirm aktualisieren. Der Bildschirm würde zu flimmern beginnen. Bei unter 30 FPS liefert ein G-Sync-Rechner alle 1/30 s = 32 ms ein Bild an den Monitor – bei unter 30 FPS mitunter dasselbe Bild wie vorher –, das daraufhin sofort dargestellt wird, während der Monitor weiterhin mit 30 Hz betrieben wird. Bei einem Rechner mit V-Sync arbeitet der Monitor hingegen weiterhin mit 60 Hz und die Grafikkarte sendet alle 16,7 ms ein Bild an den Monitor – häufiger als bei G-Sync dasselbe Bild wie das vorherige. Kommt der 3D-Beschleuniger über die Grenze von 30 FPS, wird bei G-Sync die Bildwiederholfrequenz wieder angepasst.
Die obere Grenze ist technisch bedingt. Liefert die Grafikkarte mehr FPS als der Monitor Hertz aufweist, limitiert der Monitor. Die Aufforderungen der Grafikkarte, ein fertiges Bild sofort auszuliefern, kann er nicht mehr nachkommen, da die Abfolge zu eng getaktet ist. Die Grafikkarte muss – wie bei V-Sync an – mit der Aussage warten und rendert zwischenzeitlich bereits am nächsten Frame. Sie wird bei FPS = Hertz gedeckelt.
Quelle

BBT, freesync hat gegenüber gsync auch vorteile, denn es ist zumindest in der theorie schneller. es muss nicht wie gsync ständig abfragen, ob das bild schon fertig ausgegeben wurde

Das wird auch nicht abgefragt, da der Monitor ja exakt die fertigen Frames ausgibt. Die Graka muss nicht auf den Monitor warten. Siehe Beschreibung oben.

 

[fullHDade]

Also ich sehe das Sync-Teil, egal ob es nun vornehmlich Hard- oder Software ist, als einen notwendigerweise ausgesourceten Teil der GraKa an. Damit Sync funktioniert braucht die GPU ein Feedback des Monitors.
Wie es zu funktionieren hat, gibt der GPU-Hersteller vor und der Monitorhersteller (oder Zulieferer) muss es nach den Spezifikationen umsetzten.
Hier schielt der Monitorhersteller natürlich zuerst auf seinen Gewinn und leitet daraus seinen Willen ab, wie sehr er sich der Sache widmen möchte.
Pfuscht er hier, weil er sparen will, oder was Halbgares herausgibt, um von der lukrativen Sync-Suppe zu schlürfen, ist das Ergebnis natürlich unbefriedigend.
Vielleicht lehnt sich der Monitorhersteller aber auch entspannt zurück und sagt zum GPU-Löter: „Du hast angefangen mit der Sch…, jetzt machst Du mal schön auch die Hausaufgaben für mich mit. Und was Du dann ablieferst, schraube ich ungesehen in meine Gehäuse. Uns wenns Schrott ist, dann rennen alle zum anderen GraKa-Riesen, und ich gleich hinterher. Denn, mir ist‘s egal.“

 

[DerGoldeneMesia]

Naja nicht synchron würde ja bedeuten das ein Bild zu spät oder zu früh ausgegeben wird (Gleich-Schritt), daher konnte ich damals viele spiele auch "ohne" vsync mit 50FPS spielen.

 

[fullHDade]

@webmi:
Und Dein Problem, jedenfalls das Deines Textes, ist es, dass Du nicht formuliert hast, wem Du gerade auf den Fuß treten möchtest.
Btw: Ich bin für heute raus, bis morgen (oder so).

 

[Cibo]

angenommen, monitor hat bild gerade erhalten und gibt es aus. ausgabe dauert sagen wir einfach mal 5ms. in der zwischenzeit hat aber die gpu in nur 3ms schon das nächste bild fertig und sendet es mit "bitte ausgeben" zum monitor. was passiert dann? woher kennen wir dieses verhalten? erst nach dem die 5ms lange ausgabe des bildes fertig ist, wird die gpu aufgefordert das nächste bereits fertige bild aus dem buffer zu holen und senden damit es dann als ganzes frame wieder ausgegeben werden kann.

Nur die Grafikkarte könne die Leistungsfähigkeit des Montors doch einschätzen können. Wenn die Grafikkarte weiss das dort ein 144Hz Monitor dran hängt sie den Bildfluss auf diesen Wert begrenzen bzw. auf dne maximalen G-Sync Wert.

 

[Brainorg]

dein problem ist, dass du die formulierung, die zwar sinngemäß richtig wäre, einfach aus dem text kopierst, ohne es verstanden zu haben.

letztendlich gibt der monitor an, wann der nächste zug zu fahren hat, denn die ausgabe auf einem monitor braucht auch zeit, nachdem der zug bei ihm eingetroffen ist. kommt in genau dieser zeit jetzt ein weiteres bild und der befehl, es direkt auszugeben, was passiert dann? der monitor buffert keine bilder, der gibt nur aus und sagt "bin fertig, nächster zug bitte".

angenommen, monitor hat bild gerade erhalten und gibt es aus. ausgabe dauert sagen wir einfach mal 5ms. in der zwischenzeit hat aber die gpu in nur 3ms schon das nächste bild fertig und sendet es mit "bitte ausgeben" zum monitor. was passiert dann? woher kennen wir dieses verhalten? erst nach dem die 5ms lange ausgabe des bildes fertig ist, wird die gpu aufgefordert das nächste bereits fertige bild aus dem buffer zu holen und senden damit es dann als ganzes frame wieder ausgegeben werden kann.

Nein eben nicht. ganz egal wie oft du es noch wiederholst
Ist G-Sync aktiv, kontrolliert die Grafikkarte den Monitor-Refreshzyklus. Das bedeutet, jedesmal wenn ein Bild fertig berechnet ist, sendet es die Grafikkarte zusammen mit einem Refresh-Kommando an ein entsprechend ausgerüstetes Display.
Quelle

Und ich habe, zumindest bisher auch noch nichts gegenteiliges dazu finden können.
Wenn du hier mehr weißt als so ziemlich jedes Hardwaremagazin Deutschlands, her damit

Also ich sehe das Sync-Teil, egal ob es nun vornehmlich Hard- oder Software ist, als einen notwendigerweise ausgesourceten Teil der GraKa an. Damit Sync funktioniert braucht die GPU ein Feedback des Monitors.

Leider zu spät gesehen. Siehe oben, mein Stand und so ziemlich der eines jeden Tests ist, dass die Graka keine Rückmeldung des Monitors benötigt, da sie ja dem Monitor selber das Refresh-Kommando zukommen lässt.

 

[webmi]

Habe gerade etwas mehr zum Thema gelesen. Ist doch ganz interessant, wie genau das funktioniert, hat mich jetzt jedenfalls interessiert. Meine Quelle: NVIDIA G-Sync Review

G-Sync works by manipulating the display’s VBLANK (vertical blanking interval). VBLANK is the period of time between the display rasterizing the last line of the current frame and drawing the first line of the next frame. It’s called an interval because during this period of time no screen updates happen, the display remains static displaying the current frame before drawing the next one.... The G-Sync module inside the display modifies VBLANK to cause the display to hold the present frame until the GPU is ready to deliver a new one.

VBlank ist also der Status, in dem das Display ist, nachdem es ein Bild ausgegeben hat. Durch die Manipulation zeigt das Display "quasi ununterbrochen" das eine Bild bis es etwas anderes gesagt bekommt.

You can only do so much with VBLANK manipulation though. In present implementations the longest NVIDIA can hold a single frame is 33.3ms (30Hz). If the next frame isn’t ready by then, the G-Sync module will tell the display to redraw the last frame. The upper bound is limited by the panel/TCON at this point, with the only G-Sync monitor available today going as high as 6.94ms (144Hz). NVIDIA made it a point to mention that the 144Hz limitation isn’t a G-Sync limit, but a panel limit.

Das Bild kann bei dieser Manipulation aber nur maximal 33,3ms lang gehalten werden. Was erklärt, warum G-Sync nur bis runter auf 30Hz/FPS funktioniert.

The G-Sync board itself features an FPGA and 768MB of DDR3 memory. NVIDIA claims the on-board DRAM isn’t much greater than what you’d typically find on a scaler inside a display. The added DRAM is partially necessary to allow for more bandwidth to memory (additional physical DRAM devices). NVIDIA uses the memory for a number of things, one of which is to store the previous frame so that it can be compared to the incoming frame for overdrive calculations.

Das Bild wird also wohl doch im G-Sync Modul abgelegt. Wo es für den Fall von weniger 30Hz/FPS wohl auch wieder geholt wird, um es erneut anzeigen zu können.

Enabling G-Sync does have a small but measurable performance impact on frame rate. After the GPU renders a frame with G-Sync enabled, it will start polling the display to see if it’s in a VBLANK period or not to ensure that the GPU won’t scan in the middle of a scan out. The polling takes about 1ms, which translates to a 3 - 5% performance impact compared to v-sync on. NVIDIA is working on eliminating the polling entirely, but for now that’s how it’s done.

Auch hier, wie in allen anderen deutschen und englischen Artikeln zum Thema die ich gefunden habe, ist leider nicht genau beschrieben wie im Details G-Sync nun funktioniert. Liest man aber den Text bei anandtech, könnte man folgendes Verhalten erklären:

Bild wurde ausgegeben und durch VBlank Manipulation vom G-Sync Module hält der Monitor das Bild.

Zwischenzeitlich berechnet die GPU das nächste Bild. Nach der Berechnung fragt die GPU den Monitor, ob er in einem VBlank Status ist.

Option A) Ist er das nicht, wird wieder nachgefragt (In welchem Abstand genau gepolled wird, steht da leider nicht).
Option B) Er ist in einem VBlank Status, meldet er das der GPU und die sendet das nächste Bild.

Kommt es zum erfolgreichen Handshake, sendet die GPU das neue Bild zur Ausgabe, Monitor gibt nun aus und das Verfahren beginnt erneut. GPU berechnet, pollt und wartet auf erneuten erfolgreichen Handshake vor der nächsten Berechnung. Monitor gibt noch fertig aus und wartet auf die Anfrage der GPU.

Ob das 100%ig richig ist und tatsächlich so stattfindet, geht nicht aus dem Artikel hervor. Die beschriebenen Aussagen des Artikels deuten aber auf eben genau diesen Vorgang hin.

 

[Brainorg]

In jedem anderen Artikel den man zu diesem Thema findet ist immer die rede davon, dass die Karte dem Monitor inst. zusammen mit dem neuen Frame das Refresh-Signal sendet, ohne auf eine Rückmeldung des Monitors zu warten.
Bezieht sich deine Quelle auf Modul 1 oder 2?

 

[webmi]

Du machst mich noch wahnsinnig...

Im Ernst, mag sein das es einfach nicht erwähnt wird, aber was passieren würde, wenn die GPU den Monitor das nicht fragen würde, kannste dir doch mit etwas Logik selbst erklären. Dann wären wir nämlich wieder da, wo wir doch ohne jeglichen Sync schon sind. Bild fertig -> ab damit zum Monitor, der ja auch nichts anderes machen kann, als es auszugeben. Muss ich die Logik hinter dem Handshake erklären? Es muss ja eine solche Logik geben, sonst hätte das ganze Theater doch gar keinen Sinn.

Das Release Date des Artikels sowie die Tatsache der von mir zitierten maximal möglichen 144Hz deuten doch auf v1 hin.

 

[Brainorg]

Du machst mich noch wahnsinnig...

Das freut mich (Spaß)
Das große Problem ist halt auch, dass es einfach kein richtiges Paper zu Gsync gibt.
Aber ist natürlich verständlich (Firmengeheimnis)
Da ist das bei offenen VESA schon leichter an verbindliche Infos zu kommen.

 

[webmi]

Kann einfach nicht glauben, dass du immer noch nicht verstehen willst, warum eine solche Absprache zwischen GPU und Monitor wichtig ist, sodass es eben sowohl ein Thema von GPU als auch vom Monitor ist, da es sonst zu Tearing kommen kann.

Wer jetzt auf wen wartet, wer den Fahrplan angibt, bleibt weiterhin ein "Streitfall".

Ab 144 bzw 165Hz/FPS gibt sicher das TCON bzw. das Panel, also letztendlich der Monitor den Takt vor, nach dem sich die GPU sowie G-Sync zu richten hat.
Darunter jedoch kann durchaus sowohl GPU als auch der Monitor jeweils auf den anderen Partner warten müssen, bis der Handshake zu Stande kommt.
Ab 30HZ/FPS warten natürlich alle Teilnehmer, inklusive dem Spieler vor dem System, auf die GPU.

 

[Brainorg]

Wer jetzt auf wen wartet, wer den Fahrplan angibt, bleibt weiterhin ein "Streitfall".

Ab 144 bzw 165Hz/FPS gibt sicher das TCON bzw. das Panel, also letztendlich der Monitor den Takt vor, nach dem sich die GPU sowie G-Sync zu richten hat.

Richtig. Die obere Grenze ist technisch bedingt. Liefert die Grafikkarte mehr FPS als der Monitor Hertz aufweist, limitiert der Monitor. Die Aufforderungen der Grafikkarte, ein fertiges Bild sofort auszuliefern, kann er nicht mehr nachkommen, da die Abfolge zu eng getaktet ist. Die Grafikkarte muss – wie bei V-Sync an – mit der Aussage warten und rendert zwischenzeitlich bereits am nächsten Frame. Sie wird bei FPS = Hertz gedeckelt.

Ab 30HZ/FPS warten natürlich alle Teilnehmer, inklusive dem Spieler vor dem System, auf die GPU.

Was den schlechtesten Fall darstellt. Wobei bei den niedrigen FPS eh nichts mehr hilft, um das Ruckeln zu unterbinden

 

[webmi]

Gestern Nacht Tests mit dem BIOS meiner GPU gemacht. Wollte dazu stetige maximal Last erzwingen und habe die Karte mit DS sowie x-fachem AA auf 40-60 FPS gezwungen. Auch mit G-Sync, dem zwar Zauberkräfte nachgesagt werden können, sind das leider nach wie vor Frameraten, die bei mir einen Brechreiz auslösen. Da hilft kein G-Sync Handshake mehr, nur noch eine Kotztüte.

 

[Brainorg]

Kommt halt immer auf das subjektive empfinden bzw. die games an, die man spielt.
Mich zum Bsp. haben die 100Hz des X34 überhaupt nicht abgeholt. Klar, alles etwas flüssiger... aber auf keinen Fall so wie es immer gehypt wird.
Da ist mir ein knackscharfes Bild wesentlich wichtiger bzw. bringt mir mehr Freude beim Zocken.
Jedem wie er es braucht. Mitnehmen werde ich die 120Hz bei DP1.3 UHD Monitoren letztendlich trotzdem da n1h.
Und bezüglich Gsynv bzw. freesync. Das wozu es gemacht wurde, nämlich Tearing vermeiden, tut es zu 100% zufriedenstellend.
Zaubern kann es natürlich nicht... aber das ist ja auch nicht die Aufgabe von adaptiver Synchronisation