News Ultra HD mit Freesync von Samsung ab März 2015
- Ersteller Robert
- Erstellt am
- Zur News: Ultra HD mit Freesync von Samsung ab März 2015
Krautmaster
Fleet Admiral
- Registriert
- Feb. 2007
- Beiträge
- 24.238
Daedal schrieb:
gibts dazu gute Quellen?
VBlank is meines Wissens ja schon lange Teil der Spec, nur konnten Displays nichts mit sich wechselnden Intervallen anfangen. Ich verstand die Gsync Platine / Modul bisher eher als Scalereinheit der eben dynamisch das Display selbst ansteuern kann - denn was großartig anderes als gängigen DP1.2 Standard wird Nvidia ja kaum zum Modul schicken oder Deckeln die das mit einem eigenen Protokoll?
Gibts denn da genaue Infos zur Arbeitsweise? Im Prinzip könnten ja beide quasi fast identisch mit VBlank arbeiten denn DP 1.2a braucht es dazu ja nicht, nur sieht die 1.2a Spec die mögliche dynamische (offiziell) Interpretation vor, nennt das "Adaptive Sync".
Wenn diese Scalerfähigkeiten zunehmend out of box im Display verbaut sind, dann wird die NV sicher auf ganz ähnliche oder genau gleiche Weise ansteuern wie AMD, ohne extra Modul.
Ergo beide Adaptive Sync -> bei NV heißt es Gsync, bei AMD Freesync... defakto quasi dasselbe...
Die eigentliche Komplexität ist ja mit Sicherheit nicht die, ein Bild mit Intervall X neu zu refreshen... (war eher ein technisches Thema da es die Scaler nicht konnten -> Gsync Modul als Abhilfe) - die eigentliche Komplexität liegt im Treiber den Bildinhalt zum Intervall (benötigte Rechenzeit) gut abzuschätzen und auszugeben. Die Thematik der Frame Latenzen...
Zuletzt bearbeitet:
Krautmaster schrieb:
Vielleicht ist gerade das bei G-Sync nicht notwendig. Ein proprietäres Übertragungsprotokoll für so eine Funktion würde ich zumindest so entwerfen, dass der Monitor auf Kommando sofort ein Bild annehmen kann, wobei immer die maximale Übertragungsrate verwendet wird. Variabel wäre dann die Pause bis zum nächsten Bild. Der Treiber müsste gar nichts abschätzen, sondern nur noch die fps nach oben limitieren (Adaptive Vsync).
Du kannst nicht einen Datenstrom aus einer Quelle (GPU) mit dem selben niedrigen Overhead betreiben wenn später vor der Ausgabe noch etwas hinzugefügt werden muss (GSync-Modul fügt VBLANK hinzu). Der Overhead den die Daten haben müssen um ein VBLANK noch später aufnehmen zu können und die Datenströme dann an den Monitor zur Ausgabe zusammen zu fügen ist real und technisch gehts einfach nicht anders. Fraglich ist lediglich wie hoch er ist. Man bedenke, dass das GSync Modul ja zusätzlich bestimmen muss wann der frame fertig ist zur Ausgabe. Das hat die AMD GPU alles schon erledigt und im frame eingebettet, inkls. Delta-Kompression.
Dieses ganze Format mit dem von der Vertikalfrequenz abhängigen Pixeltakt und Vblank-Pause ist doch im Prinzip ein Relikt aus Röhrenmonitorzeiten, das man bei einem neuen Protokoll komplett über Bord werfen könnte.
Die entscheidende Frage ist, ob die Panels der G-Sync-Monitore auch ohne "Voranmeldung" der Framedauer auskommen. Wenn nicht, wäre in der Tat nichts gewonnen, weil das G-Sync-Modul dann die Abschätzung übernehmen muss. Immerhin kann ein im RAM des Moduls wartender Frame nicht das Spiel ausbremsen, wenn die Schätzung danebengeht.
Die entscheidende Frage ist, ob die Panels der G-Sync-Monitore auch ohne "Voranmeldung" der Framedauer auskommen. Wenn nicht, wäre in der Tat nichts gewonnen, weil das G-Sync-Modul dann die Abschätzung übernehmen muss. Immerhin kann ein im RAM des Moduls wartender Frame nicht das Spiel ausbremsen, wenn die Schätzung danebengeht.
Es gibt keine Schätzung vorab. Der Frame kommt zum Monitor mit dem Befehl das Bild zu refreshen, in dem Moment wo es komplett ankommt. Schickt man es vorher in einen zusätzlichen RAM (GSync), dann kann es nur längere Latenzen geben und zusätzlichen Overhead beim speichern, VBLANK zufügen und wieder ausgeben des nun größeren Datenpakets.
Höhere Latenz, mehr Overhead. Anders ist das GSync Modul ja gar nicht in die Kette zu integrieren. Nun stellt sich lediglich die Frage ob dieses Modul, irgendwelche Techniken hat die das kompensieren, was zu bezweifeln ist, da ihm ja eine ganze Reihe wichtiger Standardfähigkeiten anderer Scaler fehlen. Alles was man zusätzlich macht, kostet Overhead.
Höhere Latenz, mehr Overhead. Anders ist das GSync Modul ja gar nicht in die Kette zu integrieren. Nun stellt sich lediglich die Frage ob dieses Modul, irgendwelche Techniken hat die das kompensieren, was zu bezweifeln ist, da ihm ja eine ganze Reihe wichtiger Standardfähigkeiten anderer Scaler fehlen. Alles was man zusätzlich macht, kostet Overhead.
Ergänzung ()
Warum? Laptops sparen damit Strom, weil das Bild im Desktop eben nicht 30 mal pro Sekunde erneuert werden muss wenn auf dem Bildschirm nichts passiert. Zudem lässt sich auf diese Weise das 24p stottern bei Kinofilmen für Intels GPUs ausschalten. Auch sollten andere Ruckel-Probleme wie beim scrollen auf dem Desktop damit auch der Vergangenheit angehören - Zumindest für diejenigen die auf den offenen Standard setzen beim Monitorkauf. Mit GSync Modulen sind diese Dinge nicht machbar wegen der Untergrenze von 30 Hz.JMP $FCE2 schrieb:
Bei variablem Pixeltakt muss es eine treiberseitige Schätzung geben, weil sich eine angefangene langsame Übertragung nicht mehr abbrechen lässt, wenn der nächste Frame zu früh fertig berechnet ist. Falls G-Sync immer mit maximalem Pixeltakt (also 144-Hz-Frames bei den aktuell verfügbaren Monitoren) überträgt und das Panel keinen variablen Takt verlangt, ist es gegenüber einer zweckentfremdeten Stromsparlösung im Vorteil.
Bei Kinofilmen könnte man jedes Bild zweimal darstellen und auf 48 Hz synchronisieren. Und beim Desktop macht weder Adaptive Sync noch G-Sync Sinn, weil ein manchmal ruckelnder Mauszeiger mehr nerven würde als das leichte Tearing, das bei festen 120+ Hz noch übrig bleibt.
Bei Kinofilmen könnte man jedes Bild zweimal darstellen und auf 48 Hz synchronisieren. Und beim Desktop macht weder Adaptive Sync noch G-Sync Sinn, weil ein manchmal ruckelnder Mauszeiger mehr nerven würde als das leichte Tearing, das bei festen 120+ Hz noch übrig bleibt.
Was du beschreibst gilt alles für heutige Monitore mit festen Frequenzen jedoch nicht mehr für AdaptiveSync Monitore, die das VBLANK Signal im Scaler verarbeiten können. Deshalb haben alle ASync Monitore die Unterstützung für variable Takte von 9-240 MHz.
Kinofilme werden nicht in 24 Hz gedreht sondern in 23,976, was zu einem stottern führt alle 40 sek., noch heute bei Intel GPUs, wenn eben diese nicht exakt anliegen.
Und schau dir mal solche Videos im Fenstermodus an und sag mir dann ob da ASync keinen Sinn macht auf dem Desktop. GSync natürlich nicht, da sie nur bis 30 MHz runter kommen damit.
Kinofilme werden nicht in 24 Hz gedreht sondern in 23,976, was zu einem stottern führt alle 40 sek., noch heute bei Intel GPUs, wenn eben diese nicht exakt anliegen.
Und schau dir mal solche Videos im Fenstermodus an und sag mir dann ob da ASync keinen Sinn macht auf dem Desktop. GSync natürlich nicht, da sie nur bis 30 MHz runter kommen damit.
Krautmaster
Fleet Admiral
- Registriert
- Feb. 2007
- Beiträge
- 24.238
Daedal schrieb:
das is ja alles schön und gut, aber wie gesagt... gibts da Quellen für die genaue Funktionsweise? zb bezügl. "Gsync Modul fügt VBlank hinzu" ? Wie is denn der genaue Ablauf + findet eine Rückkopplung an die GPU statt?
Wie schaut es bezüglich der Unterstützung Grafikkarten aus? Was macht AMD am DP1.2 genau anders was Nvidia davon abhalten sollte die künftigen Adaptive Sync Displays genau wie Freesync anzusprechen?
Bin wie gesagt mal auf den Vergleich gespannt. Ich denke die GPU Treiber sind nachher entscheidender. Ich bin aber bei dir dass das Gsync Modul kaum noch weiter existieren wird.
@JMP $FCE2
naja, ich meine die ganzen Treibergesichten und µRuckler selbst auf Single Karten kann ich gerade gut an meiner HD6950@70 beobachten. Ich weiß nicht woran es liegt, aber selbst bei ~ 35FPS hab ich bei neuen Titel fortlaufend Ruckler. Da hilft mir der beste Freesync / Gsync Monitor nicht. Ob der Ruckler wirklich von einem langsamen Frame her kommt oder durch ungleichmäßige Bildinhalt Änderung durch verschiedene Berechnungszeiten, kein Plan. Da kann selbst SpeedStep bei der CPU, der Turbo oder so dazwischen funken...
Fakt ist, meine 30-35 FPS die ich heut zb habe könnten 5x flüssiger dargestellt werden was nicht allein auf die Ausgabe am TV rückzuführen ist, Vsync schalte ich oftmals schon aus. 30-40 FPS is auch genau das wo die neuen Adaptiven Modi punkten würden... vorausgesetzt alles andere stimmt auch.
Zuletzt bearbeitet:
Entscheidend ist, ob der neue VESA-Standard es erlaubt, unabhängig von der variablen Vertikalfrequenz einen höheren Pixeltakt vorzugeben. Geht das nicht, muss der Treiber auf jeden Fall die Berechnungsdauer des nächsten Frames abschätzen, weil der Monitor während der Datenübertragung "tot" ist, also nicht spontan den nächsten Frame annehmen kann.
Und das 24p-Problem ließe sich, wie gesagt, leicht lösen, indem man jedes Bild zweimal schickt, und auf die resultierenden 47,952 fps dann A-Sync/G-Sync anwendet.
Eine Synchronisation auf 24p im Fenstermodus ist deshalb Unsinn, weil sie den Desktop unbedienbar machen würde. Die Mauszeigerbewegung wäre ebenfalls auf 24 fps gestutzt und kaum noch zu kontrollieren.
p.s. so fest scheint die 30-Hz-Untergrenze bei G-Sync auch nicht zu sein. Ich habe eben die alte quake3.exe gestartet und per com_maxfps auf 20 und 10 fps heruntergedrosselt. Es ist nach wie vor kein Tearing zu sehen, das Ruckeln ist grauenhaft, aber gleichmäßig, und der im Monitormenü von Acer zuschaltbare Vertikalfrequenz-Anzeigebalken folgt brav dem Framecounter von Quake.
Und das 24p-Problem ließe sich, wie gesagt, leicht lösen, indem man jedes Bild zweimal schickt, und auf die resultierenden 47,952 fps dann A-Sync/G-Sync anwendet.
Eine Synchronisation auf 24p im Fenstermodus ist deshalb Unsinn, weil sie den Desktop unbedienbar machen würde. Die Mauszeigerbewegung wäre ebenfalls auf 24 fps gestutzt und kaum noch zu kontrollieren.
p.s. so fest scheint die 30-Hz-Untergrenze bei G-Sync auch nicht zu sein. Ich habe eben die alte quake3.exe gestartet und per com_maxfps auf 20 und 10 fps heruntergedrosselt. Es ist nach wie vor kein Tearing zu sehen, das Ruckeln ist grauenhaft, aber gleichmäßig, und der im Monitormenü von Acer zuschaltbare Vertikalfrequenz-Anzeigebalken folgt brav dem Framecounter von Quake.
Mir scheint du hast dich mit der Technik überhaupt noch nicht beschäftigt. Was der Unterschied zwischen den beiden Techniken ist, steht bei VESA und Nvidia dokumentiert. DP 1.2 unterstütz kein ASync. sondern erst DP 1.2a und DP 1.3.Krautmaster schrieb:das is ja alles schön und gut, aber wie gesagt... gibts da Quellen für die genaue Funktionsweise? zb bezügl. "Gsync Modul fügt VBlank hinzu" ? Wie is denn der genaue Ablauf + findet eine Rückkopplung an die GPU statt?
Wie schaut es bezüglich der Unterstützung Grafikkarten aus? Was macht AMD am DP1.2 genau anders was Nvidia davon abhalten sollte die künftigen Adaptive Sync Displays genau wie Freesync anzusprechen?
Nvidias GPUs produzieren kein VBLANK Signal. AMDs GPUs tun das. Bei Intel ist es mir nicht bekannt. Und niemand möchte Nvidia davon abhalten künftig ASync zu verwenden, sobald ihre GPUs auch das VBLANK Signal beherrschen. GSync braucht einen Monitor mit verbauten Modul das einen VBLANK produziert.
Erkläre doch mal warum du denkst dass dies so sei?JMP $FCE2 schrieb:
Das ist totaler Unsinn und keine Lösung.JMP $FCE2 schrieb:
Auch das ist Unsinn, weil ein Mauszeiger ohne Problem mit 24 FPS bedienbar ist auf dem DesktopJMP $FCE2 schrieb:
Auch das ist Unsinn, jeder Monitor der 30 HZ darstellen kann hat mit 10 Frame pro Sekunde kein Tearing mehr . Die Frage ist ob dein Monitor auch die exakte FPS der GPU abbilden kann.JMP $FCE2 schrieb:
Ergänzung ()
Mach dich mal hier schlau was man heute anstellen muss um diesen Bug zu umgehen:
http://www.hardwareluxx.de/community/f89/verstaendnisfrage-24p-bug-erklaerung-797983.html
Vielleicht das wichtigste:
Zuletzt bearbeitet:
Daedal schrieb:
Die Datenübertragung abzubrechen, indem man mittendrin auf den anderen Bildspeicher umschaltet, führt zu Tearing, und genau das will man mit Freesync ja verhindern. Abbrechen und neuen Frame oben anfangen kommt erst recht nicht in Frage, weil der noch nicht übertragene Rest des alten Frames dann fehlt und dieser Bildteil gar nicht aktualisiert wird.
Daedal schrieb:
Natürlich ist das eine Lösung, die nebenbei jeder auf 60p eingestellte BD-Player im Prinzip so anwendet. Er verzweieinhalbfacht die Framerate von 24 auf 60 fps, indem er abwechselnd zweimal und dreimal dasselbe Bild schickt. Bei einer Vervielfachung mit ganzen Faktoren (24 auf 48, 72, 96 usw.) gibt es kein zusätzliches Pulldown-Ruckeln oder andere Nebenwirkungen, und ein Freesync- oder G-Sync-Monitor kann problemlos darauf synchronisieren.
Daedal schrieb:
Dieses träge Gezuckel wird sich niemand freiwillig antun, dagegen ist ein bisschen Tearing im nebenher laufenden Videofenster harmlos.
Daedal schrieb:
Du vergisst, dass ich auch 20 fps getestet habe. Wäre der Monitor bei 30 Hz geblieben, wäre ganz ohne Vsync mindestens jedes zweite Bild zerrissen gewesen. Und das hätte noch viel übler ausgesehen als Tearing bei 60 Hz, weil die gerissenen Bilder doppelt so lange sichtbar gewesen wären. Ein Wechsel auf Vsync-Modus mit 30 Hz hätte dagegen zu katastrophalem Pulldown-Ruckeln geführt.
Beides war definitiv nicht der Fall. Wenn da seitens G-Sync ein Notfallplan aktiv war, dann hat sich der schlauer angestellt. Es wäre z.B. möglich, dass er unterhalb von 30 fps auf 144 Hz Vsync wechselt, um Latenzen und Jitter zu minimieren.
Daedal schrieb:
Was hat das mit Freesync/G-Sync zu tun ? Der Intel-Chip kann beides nicht, damit bleibt nur die genannte Reclock-Lösung. Oder eine möglichst hohe Bildwiederholfrequenz, um je nach Modus Stolperer oder Tearing so wenig sichtbar wie möglich zu halten.
Es geht hier aber weder um Triple-Buffering (was deinen ersten Absatz obsolet macht) und genauso wenig um 3:2 Pulldown-Stottern, was den zweiten ebenso nicht zutreffend macht. Selbst mit Pulldown waren 24p nicht korrekt darstellbar. Bitte lies den Link von mir der dies besser erklärt, und zu der von dir beschriebenen Problematik zusätzlich besteht. Du hast eine Lösung für ein anderes Problem beschrieben. A/G-Sync beheben beide nicht das Problem mit dem 3:2 Pulldown. Und beide haben keine fixen Frameraten, was eben deine beschrieben Lösung unmöglich macht, welche auch das Problem nicht restlich eliminiert, sondern lediglich abschwächt.JMP $FCE2 schrieb:
Quelle zu Pulldown-Problem und Lösung dafür ohne dynamisches Sync: http://www.hifi-regler.de/hdtv/24p_ruckeln.php
Das ist was du beschrieben hast. Inkls. Soap-Effekt den viele nicht mögen.
Du hättest auch einmal in den von mir geposteten Link schauen können: http://www.hardwareluxx.de/community/f89/verstaendnisfrage-24p-bug-erklaerung-797983.html
um festzustellen worüber ich rede. Aber gut da anscheinend hier niemand irgendwo draufklickt zitiere ich mal wieder mehr als nötig:
Wie du unschwer erkennen kannst geht deine Argumentation völlig in eine andere Richtung, was nicht falsch ist, nur hat es mit dem Thema hier und Sync nichts zu tun, oder nur indirekt.
Zuletzt bearbeitet:
Daedal schrieb:
Nein, geht es nicht. Es geht nach wie vor um Beitrag #67, den ich mit Beispielen zu erklären versuche.
Also von vorne: was erscheint dir an #67 nicht plausibel ?
etoo
Lt. Commander
- Registriert
- Jan. 2008
- Beiträge
- 1.947
Krautmaster schrieb:
Ich kann die Probleme von Krautmaster nur bestätigen. Ich denke aber ,dass genau das auf fehlendes sync zurückzuführen ist und erhoffe mir von Async mehr als von Vsync ,der das ganze etwas erträglicher macht aber auch nicht nicht wirklich restlos beseitigt.
oder liege ich da falsch?
Nein, doch sag mir was dann das Gsync Modul macht. Du hast das offensichtlich überhaupt noch nicht gecheckt, dass dies lediglich ein fehlendes Feature der GPUs kompensieren soll für den Preis einer Mittelklasse GPU zusätzlich. Dafür bekommt man einen kompletten A10-7850K.
etoo schrieb:
G-Sync (also wahrscheinlich auch A-Sync) verhält sich wie V-Sync off, nur eben ohne Tearing. Wenn ein Spiel auch bei deaktiviertem Warten auf Vsync noch stottert oder hakelt, werden diese Verfahren nicht helfen. Sie lassen diesen Modus nur schöner aussehen.
Krautmaster
Fleet Admiral
- Registriert
- Feb. 2007
- Beiträge
- 24.238
Ja ich zocken derweil oft auf vsync off, aber selbst da MiniRuckler ohne Ende, 35fps sehen aus wie 1s 10fps, die nächste s 60fps... Und die Tools spucken 35 im Mittel aus. Da hilft leider auch Vsync oder AS nicht...
@ Daedal
Ich hab dich ja nicht umsonst nach ner genauen Doku gefragt was zb das GSync Modul macht. Sicher dass das Modul erst VBlank generiert und nutzt im nen nachgeschalteten Standard Scaler anzusprechen? Wenn ich es wüsste würde ich nicht fragen
Ist es nicht viel eher so dass das gsync Modul fehlende Funktionalität der TFT ersetzt, weniger der GPU? Den Scaler... der nicht dynamische Ausgaben erlaubt.
Ich finde dein Beitrag total valide. Es macht in der Tat zb bei 24p mehr Sinn dann 48p auszugeben, sonst lagged die Maus zb rum. Generell macht es Simn den höchst möglichen Vielfachen (des Monitors) auszugeben, außer es liegt Stromsparen im Fokus. Es sind schlicht 30p als Grenze bei NV da 20, als Vielfaches von 60hz - was viele Monitore heute Standard schaffen, zu wenig fürs Zocken ist.
Bei 30fps vsync on läuft der Monitor heute ja auch auf 60hz. Was macht gsync bei 20fps ingame? Gibt es es dann 40 bzw 60 hz aus? Das Limit auf den größten gemeinsamen Teiler mit der Hz Zahl des Monitors macht ja Sinn und dürfte der Grund für die 30p Untergrenze von GSync sein.
Im Notebook gibt's ja schon heute meines Wissens andere Wege das Display nur auf Kommando zu refreshen, das worauf AS auch aufbaut.
@ Daedal
Ich hab dich ja nicht umsonst nach ner genauen Doku gefragt was zb das GSync Modul macht. Sicher dass das Modul erst VBlank generiert und nutzt im nen nachgeschalteten Standard Scaler anzusprechen? Wenn ich es wüsste würde ich nicht fragen
Ergänzung ()
Daedal schrieb:
Ist es nicht viel eher so dass das gsync Modul fehlende Funktionalität der TFT ersetzt, weniger der GPU? Den Scaler... der nicht dynamische Ausgaben erlaubt.
Ergänzung ()
JMP $FCE2 schrieb:
Ich finde dein Beitrag total valide. Es macht in der Tat zb bei 24p mehr Sinn dann 48p auszugeben, sonst lagged die Maus zb rum. Generell macht es Simn den höchst möglichen Vielfachen (des Monitors) auszugeben, außer es liegt Stromsparen im Fokus. Es sind schlicht 30p als Grenze bei NV da 20, als Vielfaches von 60hz - was viele Monitore heute Standard schaffen, zu wenig fürs Zocken ist.
Bei 30fps vsync on läuft der Monitor heute ja auch auf 60hz. Was macht gsync bei 20fps ingame? Gibt es es dann 40 bzw 60 hz aus? Das Limit auf den größten gemeinsamen Teiler mit der Hz Zahl des Monitors macht ja Sinn und dürfte der Grund für die 30p Untergrenze von GSync sein.
Im Notebook gibt's ja schon heute meines Wissens andere Wege das Display nur auf Kommando zu refreshen, das worauf AS auch aufbaut.
Zuletzt bearbeitet:
Ähnliche Themen
