G-/Free-/A-Sync: framesynchronisierter Displayrefresh per variablem vblank-Intervall [Archiv] - Seite 10

Gipsel

2015-04-10, 10:25:32

Klar bringt es was, wenn der neue Frame bereits mit Fertigstellung des Refreshes fertig ist, während AdaptiveSync dann erst mit der Übertragung per DP beginnt.Dafür bringt es nichts. Der neue Refresh des Panels geschieht ohne Zeitunterschied. Ob der aus dem Speicher des GSync-Moduls oder direkt über DP kommt, macht keinen Unterschied. Man kann das Panel mit den laufend reinkommen Daten ohne Zwischenspeicherung refreshen. Genau das machen alle Gaming-Monitore in ihren low-latency-Modes (und viele billige Monitore auch). Wenn man das Bild bereits vorher "im Hintergrund" zum GSync-Modul hochgeladen hat, geht der Refresh auch nicht schneller und ist auch nicht früher fertig.
Es macht keinen Sinn RAM-Speicher auf das Modul zu löten, wenn diese nie benötigt werden. Also ist das Polling des G-Sync Modul unabhängig vom Refresh des Panel.Nicht unbedingt. RAM auf dem Modul macht Sinn, falls die Display-Engines in der GPU nicht flexibel genug sind, um einen Refresh bei Fertigstellung eines Frames zu triggern und gleichzeitg für die Einhaltung der maximalen Zeitdauer zwischen Refreshes zu sorgen. Dann teilt man sich die Aufgabe mit dem GSync-Modul. Die GPU sendet nur einen Frame, wenn einer fertig ist, das GSync-Modul sorgt für die Zwangsrefreshes. Dafür benötigt es Speicher.
Und dass es abhängig vom G-Sync Modul bzw. dessen Firmware ist, ob das FrameDoubling nun statt findet oder nicht, hast du doch selbst noch gestern gesagt:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=10583657&postcount=2194Was hat ein Firmwarebug damit zu tun?
Das FrameDoubeling geschieht also rein im G-Sync Modul, dafür auch der RAM auf dem Modul.Genau.
Das heißt auch, dass in diesem Falle ein eventueller neuer Frame bereits gesendet werden kann.Nicht unbedingt. Vielleicht passiert das. Das wäre dann das erwähnte Triple Buffering durch die Hintertür. Einen großen Vorteil würde ich daraus nicht konstruieren. Und übrigens wäre das mit einem extra (dritten) Framebuffer auf der GPU ebenfalls dort machbar. Sollte bloß nicht so viel bringen (könnte im Einzelfall sogar kontraproduktiv sein, insbesondere bei Monitoren mit begrenzten VRR-Bereichen).

Dimitri Mayakovsky

2015-04-10, 10:35:26

Dafür bringt es nichts. Der neue Refresh des Panels geschieht ohne Zeitunterschied. Ob der aus dem Speicher des GSync-Moduls oder direkt über DP kommt, macht keinen Unterschied. Man kann das Panel mit den laufend reinkommen Daten ohne Zwischenspeicherung refreshen. Genau das machen alle Gaming-Monitore in ihren low-latency-Modes (und viele billige Monitore auch). Wenn man das Bild bereits vorher "im Hintergrund" zum GSync-Modul hochgeladen hat, geht der Refresh auch nicht schneller und ist auch nicht früher fertig.
Doch, den Unterschied habe ich dir gerade erklärt/erläutert, ist nur offensichtlich nicht angekommen. Denn dein AdaptiveSync-Display kann kein Bild anzeigen, weil kein Bild da ist - das kommt ja jetzt erst noch rein.

Nicht unbedingt. RAM auf dem Modul macht Sinn, falls die Display-Engines in der GPU nicht flexibel genug sind, um einen Refresh bei Fertigstellung eines Frames zu triggern und gleichzeitg für die Einhaltung der maximalen Zeitdauer zwischen Refreshes zu sorgen. Dann teilt man sich die Aufgabe mit dem GSync-Modul. Die GPU sendet nur einen Frame, wenn einer fertig ist, das GSync-Modul sorgt für die Zwangsrefreshes. Dafür benötigt es Speicher.
Genau das sage ich doch die ganze Zeit?! :confused:

Was hat ein Firmwarebug damit zu tun?
Er zeigt:

a) das G-Sync Modul speichert jeden Frame zwischen
b) das G-Sync Modul löst den Refresh im Falle eines ausbleibenden Frame mit exakt jenem zwischengespeicherten Frame aus

Also exakt das, was ich bisher geschrieben habe:

Zwischenspeicherung der von der GPU erhaltenen Bilder, um u.A. das Framedoubling unterhalb der minimalen Refreshrate des Panels zu erzeugen.

Nicht unbedingt. Vielleicht passiert das. Das wäre dann das erwähnte Triple Buffering durch die Hintertür. Einen großen Vorteil würde ich daraus nicht konstruieren. Und übrigens wäre das mit einem extra (dritten) Framebuffer auf der GPU ebenfalls dort machbar. Sollte bloß nicht so viel bringen (könnte im Einzelfall sogar kontraproduktiv sein, insbesondere bei Monitoren mit begrenzten VRR-Bereichen).
Der Vorteil ist hier die Flexibilität.

Ich KANN immer einen alten Frame anzeigen, wenn dies notwendig ist (-> untere Refreshgrenze des Panel) und habe dafür auch alle Daten vorliegen (-> alter Frame im RAM). Ich kann also auf die Übertragung eines neuen Frame maximalst mögliche lange Warten, weil ich im Fehlerfalle, d.h. mein neuer Frame ist noch nicht fertig über DP übertragen, bis ich einen Refresh ausführen muss, einfach den alten Frame anzeigen kann.

AdaptiveSync kann exakt dies nicht, wenn der Refresh über DP übertragen werden muss. Dann hat die GPU die Wahl, ob sie alt oder neu überträgt und genau das sehen wir ja im Falle einer Refreshrate unter dem Threshold des Monitors. Dann haben wir nämlich genau den Fall von V-Sync off.

Gipsel

2015-04-10, 10:40:42

Ehrlich gesagt denke ich, dass jeder Scaler, auch in ASIC Form ohne GSync oder Freesync, einen Speicher zum Zwischenspeichern der Frames braucht. Sonst kannst Du doch schlecht Overdrive, Skalierung, OSD usw. abbilden.Man benötigt nur minimal Platz, um mit dem paketbasierten DP-Protokoll uns Skalierung klarzukommen (wenige Zeilen). OSD und so kannst Du on-the-fly drüberpappen.
Für Overdrive benötigt man tatsächlich das alte Frame, um die Unterschiede zum neuen berechnen zu können. Aber das wäre vielleicht besser im Panel selber aufgehoben. Einige Monitore machen allerdings auch aufwendigeren Kram wie forward-convolution (oder wie auch immer die das nennen), mit dem nur der Eindruck des Ghostings verringert wird (es werden gezielt etwas falsche Farbwerte gesetzt, die Integration im Auge erledigt den Rest, auf einer High-Speed-Kamera sieht man immer noch eine Art Ghosting), das spielt hier aber eher keine Rolle, es erhöht typischerweise die Latenz (weswegen es in Gaming-Monitoren sowas nicht gibt bzw. abgeschaltet ist).
Der Unterschied ist nur die Intelligenz bei der Nutzung des Speichers, speziell eben bei der Framesynchronisieren. Evtl. sind die A-Sync/Freesync Lösungen da eher einfach gestrickt (da eben nur die Schnittstellen-Spezifikation von DP abgedeckt werden müssen), während bei GSync da u.U. etwas mehr Feintuning investiert wurde, weil nVidia eben ein ganz anderen Fokus auf die Sache hat.Ich denke, daß nV ganz einfach möglichst viele GPUs unterstützen wollte und die Display-Engines dort nicht flexibel genug sind, weswegen es das Modul benötigt.

Gipsel

2015-04-10, 10:47:49

Doch, den Unterschied habe ich dir gerade erklärt/erläutert, ist nur offensichtlich nicht angekommen. Denn dein AdaptiveSync-Display kann kein Bild anzeigen, weil kein Bild da ist - das kommt ja jetzt erst noch rein.Und ich habe Dir gesagt, daß der Refresh mit dem gerade hereinkommenden Bild durchgeführt werden kann ;). Das muß nicht erst komplett übertragen werden. Kein Low-Latency-Gaming-Monitor wartet, bis die Übertragung abgeschlossen ist, um mit dem Refresh anzufangen. Es gibt also keinen Zeitvorteil.
Der Vorteil ist hier die Flexibilität.

Ich KANN immer einen alten Frame anzeigen, wenn dies notwendig ist (-> untere Refreshgrenze des Panel) und habe dafür auch alle Daten vorliegen (-> alter Frame im RAM).Genausogut kannst Du auch einfach die Daten per DP übertragen. Das Panel kümmert es nicht, ob die Daten über DP reinkommen oder aus dem Speicher des GSync-Moduls, Der Refresh dauert gleich lange.
Ich kann also auf die Übertragung eines neuen Frame maximalst mögliche lange Warten, weil ich im Fehlerfalle, d.h. mein neuer Frame ist noch nicht fertig über DP übertragen, bis ich einen Refresh ausführen muss, einfach den alten Frame anzeigen kann.Hier liegt Dein Denkfehler. Der Frame muß nicht komplett übertragen sein, um mit dem Refresh anzufangen. Auch aus dem Speicher des GSync-Moduls gehen die Daten ja klassisch über LVDS ans Panel.

fondness

2015-04-10, 10:51:42

Ich denke, daß nV ganz einfach möglichst viele GPUs unterstützen wollte und die Display-Engines dort nicht flexibel genug sind, weswegen es das Modul benötigt.

Außerdem konnte man so AMD zuvor kommen, während man sonst wohl mindestens eine Generation hinten dran wäre. Bei AMD unterstützt jede GPU ab Bonaire den DP1.2a Standard inkl. AdaptiveSync.

Aber vielleicht bringt NV zukünftig auch noch irgend welche neue Features die wirklich ohne dem Modul nicht realisierbar sind^^

dargo

2015-04-10, 10:55:43

Ich denke, daß nV ganz einfach möglichst viele GPUs unterstützen wollte und die Display-Engines dort nicht flexibel genug sind, weswegen es das Modul benötigt.
Interessanter Punkt, den man unbedingt genauer untersuchen sollte falls irgendwie möglich. Das würde nämlich bedeuten, dass neuere NV-GPUs das G-Sync Modul u.U. gar nicht erst brauchen und man es dennoch mit dem Bildschirm mitfinanziert.

MiamiNice

2015-04-10, 10:56:01

Und nebenbei streicht man noch Kohle für das Modul ein -> Win Win

Dimitri Mayakovsky

2015-04-10, 10:58:05

Und ich habe Dir gesagt, daß der Refresh mit dem gerade hereinkommenden Bild durchführen kann ;). Das muß nicht erst komplett übertragen werden. Kein Low-Latency-Gaming-Monitor wartet, bis dir Übertragung abgeschlossen ist, um mit dem Refresh anzufangen. Es gibt also keinen Zeitvorteil.
Nein, geht ja nicht, weil das Panel gerade mit Refresh des alten Frames beschäftigt ist. Erst wenn dies abgeschlossen ist, steht der Bus wieder zur Verfügung.

Genausogut kannst Du auch einfach die Daten per DP übertragen. Das Panel kümmert es nicht, ob die Daten über DP reinkommen oder aus dem Speicher des GSync-Moduls, Der Refresh dauert gleich lange.
Nur muss die DisplayEngine entscheiden, welches Frame es schicken will inklusive einer entsprechenden Sicherheitsmarge. Und genau hier wird es spannend, G-Sync braucht diese nämlich exakt nicht, weil im Problemfalle einfach das alte Frame angezeigt wird.

Hier liegt Dein Denkfehler. Der Frame muß nicht komplett übertragen sein, um mit dem Refresh anzufangen. Auch aus dem Speicher des GSync-Moduls gehen die Daten ja klassisch über LVDS ans Panel.
Nein, das ist kein Denkfehler von mir, das ist mir schon völlig klar. Nur reden wir hier über ein synchronisierte Anzeige und nicht über V-Sync off, d.h. die Übertragung eines neuen Frames kann erst beginnen, wenn der aktuell übertragende Frame fertig ist. Mitten im Frame zu switchen wäre zwar möglich, das ist ja V-Sync off, ist aber nicht mehr synchron und genau das sehen wir - tada - ja auch bei FreeSync.

Außerdem konnte man so AMD zuvor kommen, während man sonst wohl mindestens eine Generation hinten dran wäre.
Quatsch, ohne G-Sync wäre AMD gar nicht auf den Trichter FreeSync gekommen.

fondness

2015-04-10, 10:59:21

Und nebenbei streicht man noch Kohle für das Modul ein -> Win Win

Ich glaube nicht das bei den teuren FPGA viel übrig bleibt wenn überhaupt. Der Einzelhandelspreis liegt irgendwo bei $300 AFAIK wie weiter hinten verlinkt.

Dimitri Mayakovsky

2015-04-10, 11:06:04

Ich glaube nicht das bei den teuren FPGA viel übrig bleibt wenn überhaupt. Der Einzelhandelspreis liegt irgendwo bei $300 AFAIK wie weiter hinten verlinkt.
Der FPGA war nur in den ersten DIY Kits/Geräten für kürzere TTM. Inzwischen ist es ein ASIC.

dargo

2015-04-10, 11:06:41

Und nebenbei streicht man noch Kohle für das Modul ein -> Win Win
Glaube nicht, dass da viel bei rum kommt. Das Hauptziel ist eher Kundenbindung (klappt momentan wegen der hohen Bildschirmpreise eh nicht bei der Masse). Sprich, hat man einmal einen G-Sync Bildschirm hat man gar keine andere Möglichkeit als wieder Nvidia Grafikkarte zu kaufen. Und genau deshalb springe ich nicht auf diesen Zug, solange es Alternativen gibt.

aufkrawall

2015-04-10, 11:25:28

Für eine spürbare Kundenbindungs bräuchte es aber auch gewisse Stückzahlen, und ich glaub davon ist man momentan weit entfernt, bei den Preisen.

Gipsel

2015-04-10, 11:41:52

Nein, geht ja nicht, weil das Panel gerade mit Refresh des alten Frames beschäftigt ist. Erst wenn dies abgeschlossen ist, steht der Bus wieder zur Verfügung.Und G-Sync zaubert die Bilddaten zum Panel? Dort ist während eines dazwischen geschobenen Refreshes ("Frameverdopplung") der LVDS-Link zum Panel natürlich auch blockiert. Es macht keinen Unterschied.
Nur muss die DisplayEngine entscheiden, welches Frame es schicken will inklusive einer entsprechenden Sicherheitsmarge. Und genau hier wird es spannend, G-Sync braucht diese nämlich exakt nicht, weil im Problemfalle einfach das alte Frame angezeigt wird.Was? Ist nach maximaler vom Panel gemeldeter Dauer zwischen zwei Refreshes kein neues Frame da, müssen beide Techniken einen Refresh mit dem alten Bild machen. Von welchem Problemfall und welcher Sicherheitsmarge redest Du? :|
Nein, das ist kein Denkfehler von mir, das ist mir schon völlig klar. Nur reden wir hier über ein synchronisierte Anzeige und nicht über V-Sync off, d.h. die Übertragung eines neuen Frames kann erst beginnen, wenn der aktuell übertragende Frame fertig ist.Der Refresh mit dem neuen Bild kann erst anfangen, wenn der Refresh mit dem alten Frame abgeschlossen ist. Das gilt für G-Sync auch. Wo ist der Unterschied? Wenn das alte Frame komplett zum Panel übertragen wurde, kann GSync mit der Übertragung des neuen Frames beginnen. Und A-/FreeSync kann das auch. Unterscheiden tut sich allerhöchstens die Quelle der Bilddaten (DP-Link vs. Speicher des GSync-Moduls, von beiden geht es über den Scaler [das GSync-Modul ist auch einer] zum Panel).

krötenfresse

2015-04-10, 11:51:19

ich gebe zu, den thread nicht verfolgt zu haben und nicht im bilde zu sein und möchte einfach mal ein paar fragen stellen:

nutzt g-sync oder freesync auch um microruckler bei 2 grafikchips zu vermeiden?

und da ich mir demnächst einen neuen monitor kaufen will: wann kommen monitore, die sowohl freesync als auch g-sync unterstützen?

Gipsel

2015-04-10, 12:00:16

ich gebe zu, den thread nicht verfolgt zu haben und nicht im bilde zu sein und möchte einfach mal ein paar fragen stellen:

nutzt g-sync oder freesync auch um microruckler bei 2 grafikchips zu vermeiden?Es könnte etwas helfen (gegen die störenden Ruckler, gegen ungleich verteilte Frames natürlich nicht, die werden dann nur ungleich lang angezeigt). Ich weiß aber jetzt ehrlich gesagt nicht, ob die Kombination bereits unterstützt wird. Anfangs war das weder bei GSync noch FreeSync (und da ist man ja am Anfang) der Fall.

Grestorn

2015-04-10, 12:06:59

nutzt g-sync oder freesync auch um microruckler bei 2 grafikchips zu vermeiden?Nicht wirklich. Microruckler kommen nicht durch die Synchronisation mit dem Monitor und können deswegen auch nicht mit G/Freesync behoben werden.

Alle Quellen von ungleichmäßigen Frametimes addieren sich aber: Also Variationen in der Rendering-Pipeline, VRAM-Nachlade-Delays, SLI-Microruckler, VSync-Delays usw. kommen zusammen und führen zu einer zunehmend unrunden Framerate.

G/Freesync eliminiert einen der Faktoren (VSync-Delays), deswegen hilft es am Ende natürlich schon.

robbitop

2015-04-10, 12:26:13

G-Sync funktioniert auch mit SLI. Allerings nicht, wenn DSR hinzu kommt. Soll aber nachgereicht werden.

SLI produziert von Haus aus µ-Ruckler, die G-Sync nicht beheben kann. Wie aber Grestorn schreibt, ist es die Summe, die durch G-Sync auch da besser wird.

Allerdings merke ich auch trotz G-Sync, dass SLI mikroruckler bedingt weniger flüssig ist als es die angezeigte Framerate vermuten lässt.

Mit SLI hast du ca. 80...90 % mehr Leistung. Durch das µ-Ruckeln sind es aber bei gleicher gefühlter Flüssigkeit nur in etwa +50 % mehr Leistung.

aufkrawall

2015-04-10, 12:34:16

Bei dem ganzen Trara ums Modul sollte man sich auch mal wieder erinnern, dass "Gsync" eh auf Mobile per eDP kommt, ganz ohne das Hardware-Drumrum.
Der Grund, dass es das noch nicht offiziell gibt, ist ja, dass NV den Treiber noch nicht fertig hat, um Signalausfall bei 0fps zu vermeiden. Wird interessant, ob sie dann auch gleichzeitig eine Treiber-Logik einbauen, um Funktionalitäts-Parität gegenüber Desktop zu erreichen, was Refreshratenverfielfachung und Frame-Wiederholung angeht.
So gesehen wird es eine exakte Vergleichbarkeit zwischen AMD & NV geben, und wenn eine Lösung besser als die andere sein sollte, ist klar, dass der Treiber des Konkurrenten das einfach schlechter handhabt.
Die sollen mal hinnemachen...

Kartenlehrling

2015-04-10, 12:44:43

Ich glaube auch das diese Module nur für flexibilität, ein patent-dongel und weil man es vor 3 Jahren einfach nicht besser wusste,
die heutig Grafikkarten Version kann das dank ACE+VCE und cuda+nvenc warscheinlich ohne.

Dieses Virtual-vsync Version von Lucid brauchte schliesslich auch die iGPU vom Intel,
und da soll der Frame auch zwischen gespeichert werden.

krötenfresse

2015-04-10, 12:45:28

danke für eure antworten :)

zu der 2ten frage bezüglich monis, die beides unterstützen: weiß da jemand was?
sollte ich vielleicht einfach noch ein halbes jahr mit dem kauf warten?

Dimitri Mayakovsky

2015-04-10, 12:53:56

Und G-Sync zaubert die Bilddaten zum Panel? Dort ist während eines dazwischen geschobenen Refreshes ("Frameverdopplung") der LVDS-Link zum Panel natürlich auch blockiert. Es macht keinen Unterschied.
Bleib doch bitte beim Thema. Wir waren bei der Übertragung über den DP, nicht über den LVDS. Wo das im Falle A-Sync eben direkt rübergeschaufelt wird, wird es im Falle G-Sync zwischengespeichert (bzw. die Möglichkeit existiert) und somit sind beide unabhängig voneinander.

Was? Ist nach maximaler vom Panel gemeldeter Dauer zwischen zwei Refreshes kein neues Frame da, müssen beide Techniken einen Refresh mit dem alten Bild machen. Von welchem Problemfall und welcher Sicherheitsmarge redest Du? :|
Der Unterschied ist eben, wo die konkrete Bilddaten nun vor liegen. Im Falle A-Sync immer noch in der GPU, im Falle G-Sync aber schon im Monitor. Die Übertragung eines neuen Frame zum G-Sync Modul kann ebenfalls schon erfolgen, während A-Sync noch im Übertragen des alten Frames ist.

Der Refresh mit dem neuen Bild kann erst anfangen, wenn der Refresh mit dem alten Frame abgeschlossen ist. Das gilt für G-Sync auch. Wo ist der Unterschied? Wenn das alte Frame komplett zum Panel übertragen wurde, kann GSync mit der Übertragung des neuen Frames beginnen. Und A-/FreeSync kann das auch. Unterscheiden tut sich allerhöchstens die Quelle der Bilddaten (DP-Link vs. Speicher des GSync-Moduls, von beiden geht es über den Scaler [das GSync-Modul ist auch einer] zum Panel).
Richtig, der neue Refresh kann erst mit dem neuen Bild anfangen.

Mal ein theoretisches Szenario:

In dem Moment, in dem die Übertragung eines Frames über DP beginnen MUSS, ist der neue Frame fertig. A-Sync beginnt nun den alten Frame zu übertragen, G-Sync holt den alten Frame aus seinem Buffer.

Jetzt kann G-Sync aber bereits beginnen, den neuen Frame zu übertragen, in der GPU liegt er bereits. Das kann A-Sync erst dann, wenn der alte Frame fertig übertragen wurde.

Das erklärt dann natürlich auch das Ghosting. Denn während G-Sync bereits den Inhalt des nächsten Frames kennt und entsprechend den Overdrive konfigurieren kann, geht dies bei A-Sync natürlich nicht.

Bei dem ganzen Trara ums Modul sollte man sich auch mal wieder erinnern, dass "Gsync" eh auf Mobile per eDP kommt, ganz ohne das Hardware-Drumrum.
Der Grund, dass es das noch nicht offiziell gibt, ist ja, dass NV den Treiber noch nicht fertig hat, um Signalausfall bei 0fps zu vermeiden.
Soweit ich weiß gibt es bei eDP zumindest die Möglichkeit das FrameDoubeling wie es das G-Sync Modul macht durch die Display-Elektronik erledigen zu lassen. Dann kann sich die GPU, solange sich am Frameinhalt nix ändert, komplett schlafen legen.

Für Desktop hat man sich das natürlich gespart, weil zu aufwendig.

Dimitri Mayakovsky

2015-04-10, 12:55:32

die heutig Grafikkarten Version kann das dank ACE+VCE und cuda+nvenc warscheinlich ohne.
Hä? Nichts davon hat etwas mit variabler Refreshrate zu tun. Werder ACE/Cuda, noch VCE/NVENC.

fondness

2015-04-10, 13:03:46

Kartenlehrling

2015-04-10, 13:20:29

Hä? Nichts davon hat etwas mit variabler Refreshrate zu tun. Werder ACE/Cuda, noch VCE/NVENC.

Von einer variabler Refreshrate schreibe ich auch nicht, dafür sind die Hardware-Scaler "auf" den Grafikkarten und Monitor zuständig.
Davon würden wenigsten bei AMD anscheinend immer wieder andere Version verbaut, jedenfall soll deshalb auch AMD-VSR nicht so einfach für jede Grafikkarte realisierbar sein und Freesync nicht für Tahiti-gpu.
Adaptives Vsync zb. für Video soll aber funktionieren.

Auf Nachfrage verriet AMD, dass die GPUs mit unterschiedlichen „Hardware Scalern“, die für das Downsampling genutzt werden, ausgestattet sind.
Und offenbar ist nur die neuste Ausbaustufe der Tonga-GPU (R9 285) dazu in der Lage, von 3.840 × 2.160 auf 1.920 × 1.080 herunter zu skalieren.

Nichts davon hat etwas mit variabler Refreshrate zu tun.

Wenn du es doch so genau weißt,
dann halt die Gegenfrage ... was muss die Grafikkarte haben ausser einen DP1.2-Ausgang damit variabler Resfreshrate, Adaptive-, Freesync-, G-sync funktioniert?
Sonst musste doch eine Fermi GTX580 mit Displayport auch G-sync können wenn alles im Modul passiert.

Dimitri Mayakovsky

2015-04-10, 13:57:53

Von einer variabler Refreshrate schreibe ich auch nicht, dafür sind die Hardware-Scaler "auf" den Grafikkarten und Monitor zuständig.
Du bezogst dich auf das G-Sync Modul und keiner der von dir genannten Punkte hat irgendwas mit der Ausgabe des Frames zu tun.

VDavon würden wenigsten bei AMD anscheinend immer wieder andere Version verbaut, jedenfall soll deshalb auch AMD-VSR nicht so einfach für jede Grafikkarte realisierbar sein und Freesync nicht für Tahiti-gpu.
Es kann sein, dass AMD die Hardware zur Ausgabe verändert hat, hat nur leider nüchts mit ACE oder VCE zu tun.

Adaptives Vsync zb. für Video soll aber funktionieren.
Logisch, hat aber auch nichts damit zu tun. Die VCE mappt einfach das Video in den entsprechenden Bereich des Framebuffers. Mit der Ausgabe des Frames hat die aber dann immer noch nichts zu tun.

Gipsel

2015-04-10, 14:04:06

Bleib doch bitte beim Thema. Wir waren bei der Übertragung über den DP, nicht über den LVDS. Wo das im Falle A-Sync eben direkt rübergeschaufelt wird, wird es im Falle G-Sync zwischengespeichert (bzw. die Möglichkeit existiert) und somit sind beide unabhängig voneinander.Das ist genau am Thema. Es bringt halt keinen Zeitvorteil, wenn das Frame im Speicher auf dem GSync-Modul liegt. Ob das von dort über LVDS zum Panel wandert oder über den DP-Link kommt und dann über LVDS zum Panel geht macht eben keinen Unterschied. Das neue Frame landet nicht schneller beim Panel.
Der Unterschied ist eben, wo die konkrete Bilddaten nun vor liegen. Im Falle A-Sync immer noch in der GPU, im Falle G-Sync aber schon im Monitor.Das ist nur für die Funktionalität ziemlich egal.
Die Übertragung eines neuen Frame zum G-Sync Modul kann ebenfalls schon erfolgen, während A-Sync noch im Übertragen des alten Frames ist.Vielleicht geht das (wäre dann Triple Buffering und somit etwas, das man bekanntlich auch auf der GPU hinbekommt), es ändert aber nichts an der Zeitdauer, bis das Frame dann am Monitor zu sehen ist. Insofern ist es für die Flüssigkeit der Darstellung egal.
Richtig, der neue Refresh kann erst mit dem neuen Bild anfangen.

Mal ein theoretisches Szenario:

In dem Moment, in dem die Übertragung eines Frames über DP beginnen MUSS, ist der neue Frame fertig. A-Sync beginnt nun den alten Frame zu übertragen, G-Sync holt den alten Frame aus seinem Buffer.G-Sync MUSS dann auch mit dem alten Frame refreshen. Ist doch kein Unterschied.
Jetzt kann G-Sync aber bereits beginnen, den neuen Frame zu übertragen, in der GPU liegt er bereits. Das kann A-Sync erst dann, wenn der alte Frame fertig übertragen wurde.Ja na und? Bei G-Sync wird die Darstellung des Frames um die Dauer des gerade begonnenen Refreshes verzögert, weil auch dort erst der das Ende des laufenden Refreshes abgewartet werden muß, bis die Übertragung des neuen an das Panel beginnen kann. Bei FreeSync wird ebenfalls der gerade laufende Refresh abgewartet, bis die Übertragung (die dann direkt zum Panel durchgeschleift wird) des neuen Frames beginnen kann. Welchen prinzipiellen Timing-Vorteil gibt es denn? Ich sehe da keinen.
Das erklärt dann natürlich auch das Ghosting. Denn während G-Sync bereits den Inhalt des nächsten Frames kennt und entsprechend den Overdrive konfigurieren kann, geht dies bei A-Sync natürlich nicht.Die Begründung ist schlicht Schwachsinn. Was macht GSync denn, wenn es nicht gerade mit einem internen Refresh beschäftigt ist, der Panelrefresh also auch synchron zur Übertragung eines neuen Frames über Displayport gestartet wird? Du meinst doch wohl sicher nicht, daß G-Sync jeden Frame immer um einen Refresh verzögert darstellt, oder? :rolleyes:
Die Overdrive-Einstellungen ergeben sich übrigens durch den Vergleich der alten Pixelwerte mit den neuen. Das kann man für jeden Pixel einzeln bestimmen (eventuell noch mit Berücksichtigung der Dauer, die das vorherige Frame angezeigt wurde), so wie die gerade ankommen.

Dimitri Mayakovsky

2015-04-10, 14:44:31

Das ist genau am Thema. Es bringt halt keinen Zeitvorteil, wenn das Frame im Speicher auf dem GSync-Modul liegt. Ob das von dort über LVDS zum Panel wandert oder über den DP-Link kommt und dann über LVDS zum Panel geht macht eben keinen Unterschied. Das neue Frame landet nicht schneller beim Panel.
Nein, ist es nicht. Wir hatten über die Bildübertragung GPU->Monitor über den DP geredet. Jetzt springst du plötzlich vom Scaler zum Panel. Das macht keinen Sinn.

Das ist nur für die Funktionalität ziemlich egal.
Nein, ist es offensichtlich nicht. Zumindest nicht solange, so AMD nicht zeigt, dass sie auch FrameDoubling mit FreeSync beherrschen.

Vielleicht geht das (wäre dann Triple Buffering und somit etwas, das man bekanntlich auch auf der GPU hinbekommt), es ändert aber nichts an der Zeitdauer, bis das Frame dann am Monitor zu sehen ist. Insofern ist es für die Flüssigkeit der Darstellung egal.
Nein, Triple Buffering ist es, wenn die GPU drei Buffer hat und diese switcht. Mit G-Sync geht aber prinzipiel noch mehr, weil z.B. ein neuer Frame auch schon geladen werden könnte, wenn jetzt aber der nächste Frame schnell genug fertig wird, dieser vorgezogen werden kann - so er in Zeiten für den nächsten Refresh fertig ist.

Tripe Buffering ist statisch, G-Sync ist ein Können, im Sinne von: Altes Frame nehmen, wenn sonst nix da ist.

G-Sync MUSS dann auch mit dem alten Frame refreshen. Ist doch kein Unterschied.
Richtig, nimmt aber den Frame aus seinem Buffer und belegt nicht die DP-Schnittstelle, so wie das A-Sync tut. Was ich jetzt inzwischen zum 3. Mal schreibe :rolleyes:

Ja na und? Bei G-Sync wird die Darstellung des Frames um die Dauer des gerade begonnenen Refreshes verzögert, weil auch dort erst der das Ende des laufenden Refreshes abgewartet werden muß, bis die Übertragung des neuen an das Panel beginnen kann. Bei FreeSync wird ebenfalls der gerade laufende Refresh abgewartet, bis die Übertragung (die dann direkt zum Panel durchgeschleift wird) des neuen Frames beginnen kann. Welchen prinzipiellen Timing-Vorteil gibt es denn? Ich sehe da keinen.
Das neue Frame liegt um die Zeitdauer der DP-Übertragung bereits im Monitor vor.

Die Begründung ist schlicht Schwachsinn. Was macht GSync denn, wenn es nicht gerade mit einem internen Refresh beschäftigt ist, der Panelrefresh also auch synchron zur Übertragung eines neuen Frames über Displayport gestartet wird? Du meinst doch wohl sicher nicht, daß G-Sync jeden Frame immer um einen Refresh verzögert darstellt, oder? :rolleyes:
Die Begründung macht deswegen Sinn, weil A-Sync für das, was AMD macht, nie gedacht war. Sicherlich eine flexible Refreshrate, aber eben nicht auf pro-Frame Basis, sondern eher als mittelfristige Absenkung, wenn z.B. nur ein Video mit 24fps gezeigt wird.

Die Overdrive-Einstellungen ergeben sich übrigens durch den Vergleich der alten Pixelwerte mit den neuen. Das kann man für jeden Pixel einzeln bestimmen (eventuell noch mit Berücksichtigung der Dauer, die das vorherige Frame angezeigt wurde), so wie die gerade ankommen.
Der Overdrive muss nämlich auch darauf eingestellt sein, wie lange der entsprechende Frame gehalten werden soll.

Da ist natürlich genau wieder der Nachteil von A-Sync, weil es immer noch die passive GPU->Monitor Verbindung ist.

krötenfresse

2015-04-10, 14:58:33

wie sieht es eigentlich mit freesync in verbindung mit shutterbrillen-3d aus?
ist das möglich?

Grestorn

2015-04-10, 15:01:09

wie sieht es eigentlich mit freesync in verbindung mit shutterbrillen-3d aus?
ist das möglich?

Macht keinen Sinn, da 3D-Brillen auf konstante und identische Standzeit der beiden Bilder angewiesen sind.

Bei echtem VR (mit zwei getrennten Displays) könnte man es dann wieder nutzen. Am besten dann auch mit zwei dedizierten GPUs...

HPVD

2015-04-10, 15:37:21

Ephiriel

2015-04-10, 15:45:17

Was für einen Vorteil bietet denn die Frame-Vervielfachung? Es reicht doch aus, sollte kein neues Frame innerhalb der Minimalen Refreshrate fertig werden, das alte nochmal anzuzeigen, oder, sollte während des Wartens ein neues Frame fertig werden, dieses Anzeigen. So in etwa (sehr vereinfacht :tongue:):

if (NewFrameReady == True || TimeSinceLastFrame > MinRefreshRate)
Show_frame();

Was wäre denn der Vorteil von Frame-Verdoppelung im Vergleich zu dem oben beschriebenen? (Sorry, muss das nochmal vorbringen, interessiert mich wirklich).

Bezüglich Refresh, vielleicht verdeutlicht ein Timegraph, das es eigentlich keinen Unterschied machen sollte, von welchem Buffer das Display refreshed wird (Es wird mit dem Refresh sofort begonnen, nicht erst, wenn das komplette Frame übertragen wurde! ):

FreeSync:
Bild Fertig: -----------F1------------------------F2----------------------------------
DP --> Scaler:--------|--- Frame 1 ----| |--- Frame 1 ----| |--- Frame 2 ----|
Scaler --> Display-----|--- Frame 1 ---| |--- Frame 1 ----| |--- Frame 2 ----|

G-Sync:
Bild Fertig: -----------F1------------------------F2----------------------------------
DP --> G-Modul:-----|--- Frame 1 ----|-------|--- Frame 2 ----|
G-Modul--> Display---|--- Frame 1 ---| |--- Frame 1 ----| |--- Frame 2 ----|

Das einzige, was der Vorteil von G-Sync ein könnte, wenn die Übertragung Scaler-->Display wesentlich schneller geht, als Übertragung DP-->Sacler, dann für G-Sync so aussehen, während FreeSync unverändert bleibt und ein Delay um die Übertragungszeit über DP hinzu bekommt:
Bild Fertig: -----------F1------------------------F2-------------------
DP --> G-Modul:-----|--- Frame 1 ----|-------|--- Frame 2 ----|
G-Modul--> Display ------------|- F 1 -|-------|- F 1 -|---|- F2 -|

Nur weiß ich leider nicht, wie lange die einzelnen Übertragungen dauern, daher zumindest von meiner Seite theoretischer Natur die überlegung :)

Edit: Die Darstellung ist nicht ganz korrekt, da ja z.B. bei einem 144Hz Monitor die Übertragung über DP ja unter 6.9ms liegen muss, aber z.B. der Zwangsrefresh erst nach z.B. 25ms (40Hz min) erfolgen muss.
Aber ich glaube vom Prinzip sollte es trotzdem stimmen.

krötenfresse

2015-04-10, 15:54:08

Bei echtem VR (mit zwei getrennten Displays) könnte man es dann wieder nutzen.

oder bei einem polarisationsfilter-display

Am besten dann auch mit zwei dedizierten GPUs...
:confused: :uconf2:
warum nicht mit einer gpu?

Dimitri Mayakovsky

2015-04-10, 15:57:23

Was wäre denn der Vorteil von Frame-Verdoppelung im Vergleich zu dem oben beschriebenen? (Sorry, muss das nochmal vorbringen, interessiert mich wirklich).
Die Frame-Verdoppelung ist im Grund nichts anderes, als was du schon geschrieben hast, das anzeigen des alten Frames.

Unterhalb der minimalen Refreshrate (sagen wir mal 40 Hz), muss man eben 40 mal in der Sekunde was anzeigen. Wenn man nur 39 frames in der Sekunde rendert, passt das ja nicht. Also verdoppelt G-Sync generell die Frames und zeigt 78 pro Sekunde an.

So umgeht man auch das Stuttering, das FreeSync zeigt, wenn dann nach irgendwann der neue Frame doch früher fertig ist.

Das einzige, was der Vorteil von G-Sync ein könnte, wenn die Übertragung Scaler-->Display wesentlich schneller geht, als Übertragung DP-->Sacler, dann für G-Sync so aussehen, während FreeSync unverändert bleibt und ein Delay um die Übertragungszeit über DP hinzu bekommt:
Das war auch genau meine Überlegung.

Sunrise

2015-04-10, 15:59:46

hat AMD zwischenzeitlich schon irgendetwas verlauten lassen, ob sie aktuell noch Optimierungsbedarf für die Freesync-Implementierung besonders im niedrigen Frequenzbereich sehen
oder läuft aus deren Sicht mit dem aktuellen Treiber / den aktuelle verfügbaren Monitoren alles schon recht "perfekt" / genau wie geplant?

Oder haben sie bzgl einer geplanter Cossfire Unterstützung schon etwas verraten?
Es gibt generell außer PCPer aktuell keine mir bekannte Seite, die zumindest mal den Anschein erweckt, sich für das Thema wirklich zu interessieren und die Leute in Masse ein wenig tiefer aufzuklären und mal bei AMD bestimmte Dinge anzufragen.

Das sieht man auch in diesem Thread. Hier wird sich über Dinge unterhalten, die AMD bzw. NV mit ein wenig Transparenz relativ schnell klären könnte.

Dafür braucht es aber auch jemanden, der sich dafür einsetzt. So wie damals das Thema der Filterung bei 3DCenter und etwaigen anderen Seiten, das auch die IHVs (zum Glück) zum Umdenken bewegt hat.

Das ist aber natürlich auch dem Angebot generell geschuldet. Auch sind die Monitor-Hersteller nicht die schnellsten (Achtung: Ironie). Es gibt bald hoffentlich mehr Hardware und endlich mal vergleichbare Endgeräte und dann wirst du bestimmt auch mehr darüber lesen können.

Ich gehe mal davon aus, dass AMD beim Launch der 300er Serie auch nochmal groß die Trommeln rühren wird, sodass dann auch endlich mal das Henne-Ei-Problem gelöst ist.

Sowohl bei AMD als auch bei NV werden die Display Engines aber in Zukunft noch flexibler werden, ich denke davon kann man ausgehen.

Troyan

2015-04-10, 16:01:11

Gipsel

2015-04-10, 16:15:57

Nein, ist es nicht. Wir hatten über die Bildübertragung GPU->Monitor über den DP geredet. Jetzt springst du plötzlich vom Scaler zum Panel. Das macht keinen Sinn.Lese und verstehe! Dann ergibt das auch für Dich einen Sinn. ;)
Nein, Triple Buffering ist es, wenn die GPU drei Buffer hat und diese switcht.Zwei Puffer im VRAM, einer im GSync-Modul. Drei Puffer. Das Verhalten, was Du beschrieben hast, ist klassisches Triple Buffering.
Mit G-Sync geht aber prinzipiel noch mehr, weil z.B. ein neuer Frame auch schon geladen werden könnte, wenn jetzt aber der nächste Frame schnell genug fertig wird, dieser vorgezogen werden kann - so er in Zeiten für den nächsten Refresh fertig ist.G-Sync kappt die Framerate an der maximalen Refreshrate des Displays. Und wie dargelegt, bringt es keinen Vorteil für die Zeitdauer bis zur Anzeige am Display, falls ein fertiges Frame während eines Refreshes schon in den Speicher auf dem GSync-Modul hochgeladen wird.
Tripe Buffering ist statisch, G-Sync ist ein Können, im Sinne von: Altes Frame nehmen, wenn sonst nix da ist.:freak:
Richtig, nimmt aber den Frame aus seinem Buffer und belegt nicht die DP-Schnittstelle, so wie das A-Sync tut. Was ich jetzt inzwischen zum 3. Mal schreibe :rolleyes:Du ignorierst aber vermutlich auch bereits zum dritten Mal, daß das ziemlich unerheblich ist, weil das Interface zum Panel trotzdem belegt ist, man kann also auch nicht schneller refreshen. Es bringt Dir also nichts.
Das neue Frame liegt um die Zeitdauer der DP-Übertragung bereits im Monitor vor.Was Dir nichts bringt, da es auch nicht früher angezeigt werden kann.
Die Begründung macht deswegen Sinn, weil A-Sync für das, was AMD macht, nie gedacht war. Sicherlich eine flexible Refreshrate, aber eben nicht auf pro-Frame Basis, sondern eher als mittelfristige Absenkung, wenn z.B. nur ein Video mit 24fps gezeigt wird.Das ist schlicht Schwachsinn.
Der Overdrive muss nämlich auch darauf eingestellt sein, wie lange der entsprechende Frame gehalten werden soll.Da GSync nicht in die Zukunft schauen kann, geht das gar nicht. Man kann es nur auf vergangene Dinge justieren (einfache Abschätzung: der nächste Frame wird genau so lange angezeigt, wie der letzte [oder das Mittel aus den letzten, oder was auch immer]). Und das kann der Monitor natürlich auch mit A-/FreeSync tun.
Da ist natürlich genau wieder der Nachteil von A-Sync, weil es immer noch die passive GPU->Monitor Verbindung ist.Der Satz ergibt keinen Sinn.

Ephiriel

2015-04-10, 16:17:25

Unterhalb der minimalen Refreshrate (sagen wir mal 40 Hz), muss man eben 40 mal in der Sekunde was anzeigen. Wenn man nur 39 frames in der Sekunde rendert, passt das ja nicht. Also verdoppelt G-Sync generell die Frames und zeigt 78 pro Sekunde an.

So umgeht man auch das Stuttering, das FreeSync zeigt, wenn dann nach irgendwann der neue Frame doch früher fertig ist.

Das Stuttering kommt doch bei FreeSync nur zustande, weil da aktuell, sollte ein Frame nur um 1ms zu spät fertig werden, trotzdem volle 25ms (40Hz Min. Refresh) gewartet wird, bis das neue Frame angezeigt wird, was ja überhaupt keinen Sinn ergibt, daher auch die Überlegung von Gipsel, das es sich hier um einen Bug handelt.

Bei einer Implementierung wie von mir beschrieben (wüsste nicht was dagegen spricht, es so zu machen), sollte das ja auch nicht auftreten, sondern würde das neue Frame gleich nach der Übertragung des alten Frames angezeigt werden. Absolut Worst case ist dann 1/max. Refreshrate * 2 delay, das kann aber bei Frame-Verdoppelung genauso auftreten. (theoretisch sogar öfter, da öfters ein Frame an das Display übertragen wird)

fondness

2015-04-10, 16:20:33

hat AMD zwischenzeitlich schon irgendetwas verlauten lassen, ob sie aktuell noch Optimierungsbedarf für die Freesync-Implementierung besonders im niedrigen Frequenzbereich sehen
oder läuft aus deren Sicht mit dem aktuellen Treiber / den aktuelle verfügbaren Monitoren alles schon recht "perfekt" / genau wie geplant?

Oder haben sie bzgl einer geplanter Cossfire Unterstützung schon etwas verraten?

Crossfire-Unterstützung wurde für April angekündigt. Zu dem anderen gibt es noch keine offizielle Stellungnahme außer:

Below the minimum refresh rate things get dicey. I believe that NVIDIA’s implementation of offering a variable frame rate without tearing is superior to simply enabling or disabling VSync again, as the issues with tearing and stutter not only return but are more prominent at lower frame rates. When I pressed AMD on this issue during my briefing they admitted that there were things they believed could work to make that experience better and that I should “stay tuned.” While that doesn’t help users today, AMD thinks that these problems can be solved on the driver side without a change to the AdaptiveSync specification and without the dedicated hardware that NVIDIA uses in desktop G-Sync monitors.

http://www.pcper.com/reviews/Displays/AMD-FreeSync-First-Impressions-and-Technical-Discussion

Gipsel

2015-04-10, 16:21:42

Was wäre denn der Vorteil von Frame-Verdoppelung im Vergleich zu dem oben beschriebenen? (Sorry, muss das nochmal vorbringen, interessiert mich wirklich).

Bezüglich Refresh, vielleicht verdeutlicht ein Timegraph, das es eigentlich keinen Unterschied machen sollte, von welchem Buffer das Display refreshed wird (Es wird mit dem Refresh sofort begonnen, nicht erst, wenn das komplette Frame übertragen wurde! ):Ganz genau so sieht es aus.
Das einzige, was der Vorteil von G-Sync ein könnte, wenn die Übertragung Scaler-->Display wesentlich schneller geht,Das ist aber nicht der Fall, die Panelelektronik akzeptiert die Bilddaten über LVDS eben nur genau so schnell, wie es der maximale Refreshrate des Panels erlaubt. Dies könnte eventuell mit speziellen Panels in Zukunft mal anders aussehen, das könnte dann aber auch mit FreeSync genutzt werden, solange man nicht an das Bandbreitenlimit von DP stößt.

myMind

2015-04-10, 16:47:37

nVidia sagt, dass deren Tegra X1 über HDMI 5ms benötigt, um ein Frame (1080p) an einen Fernsehr zu senden. Das entspricht annährend 71% der benötigten Zeit für einen Refresh bei einem 144Hz Panel.
Diese Zeiten sind zwar gut zu wissen. Das sind konstante Verzögerungen, die immer obenauf kommen. Wenn es hier unterschiede bei DP, HDMI oder DVI gibt wäre das schon spannend.
Interessanter sind hier m.E. nach die Zeiten zwischen den Bildern. Das geht in der Diskussion leider immer mal wieder durcheinander.

Gipsel

2015-04-10, 16:53:10

nVidia sagt, dass deren Tegra X1 über HDMI 5ms benötigt, um ein Frame (1080p) an einen Fernsehr zu senden. Das entspricht annährend 71% der benötigten Zeit für einen Refresh bei einem 144Hz Panel.Wo sagt nVidia das?
Insbesondere bei HDMI oder DVI muß das Signal synchron zum Pixeltakt übertragen werden, auf den sich das Display synchronisiert. Ohne spezielle Panelelektronik würde das also gar nicht gehen, wenn die das Display nicht mit knapp 200Hz Refresh fahren.

Grestorn

2015-04-10, 16:54:43

oder bei einem polarisationsfilter-display

:confused: :uconf2:
warum nicht mit einer gpu?

Weil die beiden Frames dann gleichzeitig (und somit auch gleich schnell) berechnet werden können. Geht sicher auch mit einer GPU, aber VR ist geradezu wie gemacht für Dual-GPU, IMO.

Troyan

2015-04-10, 16:56:11

Dimitri Mayakovsky

2015-04-10, 17:38:15

Lese und verstehe! Dann ergibt das auch für Dich einen Sinn. ;)
Nein, da gibt es keinen Sinn plötzlich zwischen völlig unterschiedlichen Sachverhalten hin- und her zu springen, wie es gerade ind en Kram passt.

Zwei Puffer im VRAM, einer im GSync-Modul. Drei Puffer. Das Verhalten, was Du beschrieben hast, ist klassisches Triple Buffering.
Ach Gipsel, erzähl doch nicht so einen Quatsch. Triple Buffering bezieht sich natürlich AUSSCHLIESSLICH auf die GPU. Nicht darauf, ob der Frame noch woanders gespeichert wurde :facepalm:

Exakt das Gegenteil von "klassisch" Triple Buffering.

G-Sync kappt die Framerate an der maximalen Refreshrate des Displays. Und wie dargelegt, bringt es keinen Vorteil für die Zeitdauer bis zur Anzeige am Display, falls ein fertiges Frame während eines Refreshes schon in den Speicher auf dem GSync-Modul hochgeladen wird.
Und wieder pullt er einen typischen Gipsel und springt vom einen Ende der Fahnenstange (Refreshrate UNTERHALB des Panel Threshold) zum anderen Ende (Refreshrate OBERHALB des Panel Threshold). :facepalm:

Aber wahrscheinlich bin ich wieder nur zu blöd die Intention dahinter zu verstehen :rolleyes:

:freak:
Nicht verstanden?

Gut, dann nochmal:

Triple Buffering ist ein STATISCHER Vorgang. D.h. die GPU hat DREI Buffer und nutzt diese als A, B und C um jeweils a) das Bild zu rendern und b) um es auszugeben. Das tauscht periodisch. Du hast also immer einen Buffer, aus dem der RAMDAC den Frame ausliest und an den Monitor schickt und einen Buffer, in den die GPU rendert. Ist die GPU fertig mit rendern, nutzt sie den dritten Buffer. Bei VSync wechselt der RAMDAC jeweils vom aktuellen Buffer zum nächsten mit einem fertigen Bild.

Das ist aber wie gesagt STATISCH. Das ist IMMER so.

Wenn im G-Sync Modul dagegen ein Frame zwischen gespeichert wird, dann kann dieser auch durchaus unbenutzt bleiben.

Beispiel:

Neuer Frame kommt 1 ms zu spät, FrameDoubleing wird eingesetzt. Der neue Frame schon mal per DP übertragen. Jetzt ist die GPU so flink mit dem nächsten (3.) Frame, dass dieser fertig ist, bevor die Zeit für DP-Übertragung für den nächsten Frame vorbei ist - Zack, das G-Sync Modul schickt statt dem schon hoch gelanden 2. Frame den 3. zum Panel. Nix Triple Buffering.

Also ein KANN statt ein MUSS.

Verstanden?

Du ignorierst aber vermutlich auch bereits zum dritten Mal, daß das ziemlich unerheblich ist, weil das Interface zum Panel trotzdem belegt ist, man kann also auch nicht schneller refreshen. Es bringt Dir also nichts.
Natürlich wird das LVDS Interface zum Panel auch mal frei, du Schlauberger. Der Frame steht dann schon im Monitor (-> G-Sync) bereit, statt jetzt erst über DP übertragen zu werden.

Das ist schlicht Schwachsinn.
:facepalm:

Nein, natürlich nicht. Lies gern mal die entsprechenden Specs, besonders interessant die eDP Spec 1.0 von 2008, die das was wir heute als AdaptiveSync kennen, schon längst drin hatten. Damals aber kein Gaming-Feature, als das, wofür AMD es missbraucht, sondern ein Stromsparfeature.

Eben, um z.B. ein 60Hz Panel in einem Mobilgerät nicht unnötig Strom verbrauchen zu lassen, wenn 24Hz völlig ausreichend wäre für den Film, der gerade angezeigt wird.

Wie gesagt eine mittelfristige Anpassung der Refreshrate, nicht die sehr kurzfristige, wie sie G-Sync erlaubt. Und auch IMHO genau der Grund, warum AMD ein FreeSync-Label drauf pappt. Weil eben nicht alle A-Sync Monitore in der Lage sein werden, den schnellen Änderungen der Refreshrate Folge leisten zu können.

Da GSync nicht in die Zukunft schauen kann, geht das gar nicht. Man kann es nur auf vergangene Dinge justieren (einfache Abschätzung: der nächste Frame wird genau so lange angezeigt, wie der letzte [oder das Mittel aus den letzten, oder was auch immer]). Und das kann der Monitor natürlich auch mit A-/FreeSync tun.
Nein, natürlich kann G-Sync nicht in die Zukunft schauen, habe ich so auch nirgends behauptet. Sehr wohl aber, ist die Kommunikation zwischen GPU und G-Sync Modul deutlich aufgebohrt gegenüber FreeSync.

Das sehen wir eben im kompletten Abschalten von FreeSync im Threshold unterhalb der minimalen Refreshrate des Panels.

Der Satz ergibt keinen Sinn.
Natürlich, für manche Leute nicht, aber da hat der Satz keine Schuld dran ;)

Auch bei FreeSync ist immer noch der Monitor der Master, der die Refreshrate vorgibt, die GPU muss ihre Wünsche vorgeben und kann mitnichten einen Frame schicken, wenn sie möchte. Dies ist bei G-Sync anders.

Dimitri Mayakovsky

2015-04-10, 17:38:43

Das Stuttering kommt doch bei FreeSync nur zustande, weil da aktuell, sollte ein Frame nur um 1ms zu spät fertig werden, trotzdem volle 25ms (40Hz Min. Refresh) gewartet wird, bis das neue Frame angezeigt wird, was ja überhaupt keinen Sinn ergibt, daher auch die Überlegung von Gipsel, das es sich hier um einen Bug handelt.
Es ist schwer da mit Bug zu argumentieren, da ein Frame ja immer noch an den Monitor gesendet wird. FreeSync wird nur völlig deaktiviert und statt dessen auf V-Sync off geswitcht, wenn man unterhalb der minimalen Panel-Refreshrate fällt.

Im Gegenteil, die GPU wartet gar keinen Refresh ab, unterhalb des Panel-Threshold macht die GPU den Bufferflip sofort, wenn der Frame fertig ist.

Heißt: Ist bei FreeSync der Frame 0,1ms zu spät, wird 0,1ms lang der alte Frame gezeichnet, danach der neue. Heißt: Tearing. G-Sync zeichnet den alten Frame zuende und zeichnet DANN den neuen. Und zwar wahrscheinlich am Panellimit, als 60/144/120Hz.

Bei einer Implementierung wie von mir beschrieben (wüsste nicht was dagegen spricht, es so zu machen), sollte das ja auch nicht auftreten, sondern würde das neue Frame gleich nach der Übertragung des alten Frames angezeigt werden. Absolut Worst case ist dann 1/max. Refreshrate * 2 delay, das kann aber bei Frame-Verdoppelung genauso auftreten. (theoretisch sogar öfter, da öfters ein Frame an das Display übertragen wird)
Genau dies tut das G-Sync Display. Mit dem Vorteil, das neue Frame bereits im Monitor vorrätig zu haben (Speicher des G-Sync Moduls) und sofort an die Panelelektronik weiter geben zu können.

Auf der Folie über Grid.

TVs und Monitore haben doch eigenen Speicher, um entsprechende Bildbearbeitungen durchzuführen. Die 5ms sind nicht weiteres zusätzliche Latenz bevor das Endgerät überhaupt etwas durchführen kann.
Welche meinst du? Diese?

http://2.f.ix.de/imgs/18/1/4/4/4/0/8/4/Nvidia_Grid-1b4540dcd3ebc39d.jpeg

krötenfresse

2015-04-10, 17:47:30

Gipsel

2015-04-10, 21:01:05

Auf der Folie über Grid.

TVs und Monitore haben doch eigenen Speicher, um entsprechende Bildbearbeitungen durchzuführen. Die 5ms sind nicht weiteres zusätzliche Latenz bevor das Endgerät überhaupt etwas durchführen kann.Link please. Die Erklärung hat so nichts mit der Übertragungsdauer zu tun.

========================

Nein, da gibt es keinen Sinn plötzlich zwischen völlig unterschiedlichen Sachverhalten hin- und her zu springen, wie es gerade ind en Kram passt.Das sind eben keine völlig unterschiedlichen Sachverhalte. Die GPU schickt die Bilddaten typischerweise genau so schnell zum Monitor, wie sie das Panel entgegennehmen kann (was 1/Refreshrate pro Frame dauert). Ist doch nicht so schwer zu verstehen.

Ach Gipsel, erzähl doch nicht so einen Quatsch. Triple Buffering bezieht sich natürlich AUSSCHLIESSLICH auf die GPU. Nicht darauf, ob der Frame noch woanders gespeichert wurde :facepalm:

Exakt das Gegenteil von "klassisch" Triple Buffering.Es ist vom Verhalten was Du beschreibst genau Triple Buffering. Zwei Buffer im VRAM, einer auf dem GSync-Modul.
Und wieder pullt er einen typischen Gipsel und springt vom einen Ende der Fahnenstange (Refreshrate UNTERHALB des Panel Threshold) zum anderen Ende (Refreshrate OBERHALB des Panel Threshold). :facepalm:Du hast davon geredet, ein Frame überspringen zu wollen, also daß während der Refresh mit dem aktuellen Frame läuft, nicht nur das nächste, sondern sogar bereits das übernächste Frame fertig wird. Wie soll das gehen, ohne eine Framerate oberhalb der maximalen Refreshrate des Displays? :rolleyes:
Aber wahrscheinlich bin ich wieder nur zu blöd die Intention dahinter zu verstehen :rolleyes:In diesem Punkt will ich Dir nicht widersprechen.
Nicht verstanden?Es ist Blödsinn.
Gut, dann nochmal:

Triple Buffering ist ein STATISCHER Vorgang. D.h. die GPU hat DREI Buffer und nutzt diese als A, B und C um jeweils a) das Bild zu rendern und b) um es auszugeben. Das tauscht periodisch. Du hast also immer einen Buffer, aus dem der RAMDAC den Frame ausliest und an den Monitor schickt und einen Buffer, in den die GPU rendert. Ist die GPU fertig mit rendern, nutzt sie den dritten Buffer. Bei VSync wechselt der RAMDAC jeweils vom aktuellen Buffer zum nächsten mit einem fertigen Bild.

Das ist aber wie gesagt STATISCH. Das ist IMMER so.

Wenn im G-Sync Modul dagegen ein Frame zwischen gespeichert wird, dann kann dieser auch durchaus unbenutzt bleiben.
Erstmal, was ist klassisches Triple Buffering?
Wikipedia sagt (http://en.wikipedia.org/wiki/Multiple_buffering#Triple_buffering):
In triple buffering the program has two back buffers and can immediately start drawing in the one that is not involved in such copying. The third buffer, the front buffer, is read by the graphics card to display the image on the monitor. Once the monitor has been drawn, the front buffer is flipped with (or copied from) the back buffer holding the last complete screen. Since one of the back buffers is always complete, the graphics card never has to wait for the software to complete. Consequently, the software and the graphics card are completely independent, and can run at their own pace. Finally, the displayed image was started without waiting for synchronization and thus with minimum lag.

Due to the software algorithm not having to poll the graphics hardware for monitor refresh events, the algorithm is free to run as fast as possible. This can mean that several drawings that are never displayed are written to the back buffers. This is not the only method of triple buffering available, but is the most prevalent on the PC architecture where the speed of the target machine is highly variable.Das ist das "klassische" TripleBuffering, was die GPUs natürlich immer noch können. Daß in letzter Zeit Framequeues (bei der die Framerate auf die Refreshrate limitiert wird und keine Frames verworfen werden, was die Latenz erhöht) an Beliebtheit gewonnen haben, ist eine reine Softwaresache, das ist nicht prinzipiell so (es ist wie gesagt sogar eine eher neuere Entwicklung).
Beispiel:
Neuer Frame kommt 1 ms zu spät, FrameDoubleing wird eingesetzt. Der neue Frame schon mal per DP übertragen. Jetzt ist die GPU so flink mit dem nächsten (3.) Frame, dass dieser fertig ist, bevor die Zeit für DP-Übertragung für den nächsten Frame vorbei ist - Zack, das G-Sync Modul schickt statt dem schon hoch gelanden 2. Frame den 3. zum Panel. Nix Triple Buffering.Ich zähle da drei Puffer, zwei auf der GPU einen auf dem GSync-Modul. In den von Dir beschriebenen Fällen hast Du zwei Backbuffer auf der GPU (der "offizielle" Frontbuffer im VRAM wird nicht direkt für das Scanout benutzt sondern nur über DP zum GSync-Modul kopiert) und den Frontbuffer im Speicher des GSync-Moduls.
Zähle doch mal nach! Frame 1 liegt im Speicher des GSync-Moduls (Frontbuffer), daraus läuft ein Refresh, GPU rendert Frame 2, welches dann im VRAM liegt und startet dann mit Frame 3, welches natürlich ebenfalls in einen dritten Puffer geschrieben werden muß. Drei unterschiedliche Frames gleichzeitig irgendwo im Speicher. Triple Buffering.

Gleiches Beispiel ohne Speicher auf dem GSync-Modul:
Frame 1 im momentanen Frontbuffer wird gerade über DP-Port zum Refresh benutzt. GPU stellt Frame 2 fertig, der liegt in einem Backbuffer und GPU fängt mit Rendern des dritten Frames in den dritten Puffer an. Wenn das beim Ende des aktuell laufenden Refreshes mit Frame 1 bereits fertig ist, startet der Refresh mit dem letzten fertiggestellten Frame (Frame 3). Gleiches Verhalten.

Okay, einen Unterschied gibt es. Die Methode auf der GPU funktioniert tatsächlich einwandfrei, die mit dem GSync-Modul nur, wenn die GPU und das GSync-Modul noch ein paar mehr Tricks können. Denk mal genau über den zeitlichen Ablauf nach. Das neue Frame kommt in Deinem Beispiel 1ms zu spät für den Refresh, der läuft also schon seit einer Millisekunde. Das neue Frame wird dann schon im Hintergrund übertragen. Wie lange dauert das z.B. bei einem 144Hz-Monitor? 6,9ms? Nach welcher Zeit ist der Refresh fertig? Wohl nach grob 5,9ms (1ms war ja schon vorbei). Kann die GPU eigentlich dann nach 5,9ms überhaupt schon das dritte Frame senden, wenn die Übertragung des zweiten noch nicht beendet ist? Woher weiß die GPU, daß sie die Übertragung des laufenden Frames abbrechen kann? Geht das überhaupt, ohne das man Tearing oder eine zusätzliche Verzögerung riskiert?
Die Probleme hast Du bei der GPU-seitigen Lösung schon mal nicht. ;)
Natürlich wird das LVDS Interface zum Panel auch mal frei, du Schlauberger. Der Frame steht dann schon im Monitor (-> G-Sync) bereit, statt jetzt erst über DP übertragen zu werden.Und das bringt Dir wieviele Nanosekunden? Bringt es überhaupt etwas?
Welchen Unterschied macht es, ob die Daten den Weg DP-Port=>Konversion auf LVDS=>Panel nehmen, oder GSYNC-Speicher=>Konversion auf LVDS=>Panel? ;)
Nein, natürlich nicht. Lies gern mal die entsprechenden Specs, besonders interessant die eDP Spec 1.0 von 2008, die das was wir heute als AdaptiveSync kennen, schon längst drin hatten. Damals aber kein Gaming-Feature, als das, wofür AMD es missbraucht, sondern ein Stromsparfeature.Das "Argument" kann man nur hanebüchen nennen. Was nutzt denn nV für GSync? Doch exakt die gleiche Sache (siehe Threadüberschrift).
Dein Argument gleicht in etwa dem, daß Räder ja wohl nicht das Richtige für ein Auto wären, da man damit doch im Mittelalter schon Kutschen betrieben hätte. :freak:
Nein, natürlich kann G-Sync nicht in die Zukunft schauen, habe ich so auch nirgends behauptet. Sehr wohl aber, ist die Kommunikation zwischen GPU und G-Sync Modul deutlich aufgebohrt gegenüber FreeSync.Du meinst die Kommunikation über DP? Da benutzt nV auch nichts, was wirklich dem Standard widerspricht und legt nur variable Pausen zwischen den Frames ein. Genau wie A-/FreeSync auch. Bidirektionale Kommunikation ist halt bei DP erlaubt. Falls GSync das für Handshakes zwischen GPU und Modul nutzt, ist das nicht unbedingt ein Vorteil oder "aufgebohrt", sondern größtenteils wohl konzeptionell unnötig und nur erforderlich, weil nVs Displayengines nicht direkt ASync-kompatibel sind, sprich eine externe Hilfe benötigen, um die Minimalrefreshrate einhalten zu können. Spricht etwas gegen diese Interpretation?
Und der Rest der Kette? Althergebrachter FPD-Link mit LVDS-Signaling. Und wenn mittelfristig eDP/iDP-Support kommt, was meinst Du wohl wie nV variable Refreshraten unterstützen wird?
Auch bei FreeSync ist immer noch der Monitor der Master, der die Refreshrate vorgibt, die GPU muss ihre Wünsche vorgeben und kann mitnichten einen Frame schicken, wenn sie möchte. Dies ist bei G-Sync anders.:freak:
Bei A-/FreeSync teilt der Monitor mit, welchen Bereich an Refreshraten er unterstützt, dann sendet die GPU fröhlich drauflos und muß sich nur an die Grenzen halten. Bei GSync darf laut einigen Aussagen die GPU ständig beim Monitor nachfragen, ob er ein neues Frame akzeptieren kann (Polling, daher der leichte Performanceverlust). Mal abgesehen von den Implementationsunterschieden ist die Grafikkarte im variablen Bereich natürlich der Master, bei beiden.
====================
Im Gegenteil, die GPU wartet gar keinen Refresh ab, unterhalb des Panel-Threshold macht die GPU den Bufferflip sofort, wenn der Frame fertig ist.

Heißt: Ist bei FreeSync der Frame 0,1ms zu spät, wird 0,1ms lang der alte Frame gezeichnet, danach der neue. Heißt: Tearing.Bei FreeSync ist wählbar ob VSync außerhalb des variablen Bereiches an oder aus sein soll.
Genau dies tut das G-Sync Display. Mit dem Vorteil, das neue Frame bereits im Monitor vorrätig zu haben (Speicher des G-Sync Moduls) und sofort an die Panelelektronik weiter geben zu können.Was irgendwie gar kein Vorteil ist, wie schon festgestellt wurde.
Welche meinst du? Diese?

http://2.f.ix.de/imgs/18/1/4/4/4/0/8/4/Nvidia_Grid-1b4540dcd3ebc39d.jpegDie zeigt nur nicht das, was Troyan sagte.

Pentium M

2015-04-10, 21:57:36

Man fragt sich wer ist Don Quijote und wer die Windmühle.

Effe

2015-04-10, 22:10:07

Man fragt sich wer ist Don Quijote und wer die Windmühle.
Ich frage mich eher, wo die Motivation herkommt, F- bzw. A-Sync verzweifelt schlechtreden zu wollen. Aber mann kenn ja den "Diskussionsstil" und den AMD-Hass des bald wieder Gesperrten.

samm

2015-04-10, 23:16:59

noch eine blöde frage:
freesync könnte ja auch auf nvidia-karten laufen, wenn nv es wollen.

müssten sie eurer meinung nach dafür neue karten bringen, oder schafft das jede gsync-karte durch eine änderung im treiber?Treiber allein wird nicht reichen. Dennoch wird es bei neueren nVidia-Karten wohl schon möglich sein, mit Adaptive Sync (FreeSync ist das AMD-Label für ihre Seite des Ganzen) umzugehen, wenn es die aktuelle Mobile-Generation offensichtlich schafft (wenn auch ebenfalls unter dem Label "GSync")

Dimitri Mayakovsky

2015-04-11, 12:29:06

Das sind eben keine völlig unterschiedlichen Sachverhalte. Die GPU schickt die Bilddaten typischerweise genau so schnell zum Monitor, wie sie das Panel entgegennehmen kann (was 1/Refreshrate pro Frame dauert). Ist doch nicht so schwer zu verstehen.
Nur leider tut das die GPU in dem Falle, über den wir hier reden, gar nicht mehr.

Es ist vom Verhalten was Du beschreibst genau Triple Buffering. Zwei Buffer im VRAM, einer auf dem GSync-Modul.
Du hast offensichtlich Triple Buffering nicht verstanden.

Du hast davon geredet, ein Frame überspringen zu wollen, also daß während der Refresh mit dem aktuellen Frame läuft, nicht nur das nächste, sondern sogar bereits das übernächste Frame fertig wird. Wie soll das gehen, ohne eine Framerate oberhalb der maximalen Refreshrate des Displays? :rolleyes:
Was sagt dir das Wort "überspringen"?

In diesem Punkt will ich Dir nicht widersprechen.
Zumindest zeigst du mit deinen Ausflüchten, dass dir die Argumente fehlen. Gut zu wissen.

Es ist Blödsinn.
Nein, im Gegenteil. Ich gebe zu, dass es den gemeinen Forenuser vllt überfordert, aber ich dachte hier wäre man Technikaffin?

Erstmal, was ist klassisches Triple Buffering?
Wikipedia sagt (http://en.wikipedia.org/wiki/Multiple_buffering#Triple_buffering):
In triple buffering the program has two back buffers and can immediately start drawing in the one that is not involved in such copying. The third buffer, the front buffer, is read by the graphics card to display the image on the monitor.
Danke dafür, dass du selbst darlegst, dass G-Sync mitnichten Triple Buffering ist.

Wäre aber gar nicht notwendig gewesen :tongue:

Das ist das "klassische" TripleBuffering, was die GPUs natürlich immer noch können. Daß in letzter Zeit Framequeues (bei der die Framerate auf die Refreshrate limitiert wird und keine Frames verworfen werden, was die Latenz erhöht) an Beliebtheit gewonnen haben, ist eine reine Softwaresache, das ist nicht prinzipiell so (es ist wie gesagt sogar eine eher neuere Entwicklung).
Ja und hat leider null mit G-Sync zu tun.

Ich zähle da drei Puffer, zwei auf der GPU einen auf dem GSync-Modul. In den von Dir beschriebenen Fällen hast Du zwei Backbuffer auf der GPU (der "offizielle" Frontbuffer im VRAM wird nicht direkt für das Scanout benutzt sondern nur über DP zum GSync-Modul kopiert) und den Frontbuffer im Speicher des GSync-Moduls.
Also ist es kein Triple Buffering, sondern 2+1. Danke.

Dass das bei dir aber auch so lange dauert....

Zähle doch mal nach! Frame 1 liegt im Speicher des GSync-Moduls (Frontbuffer), daraus läuft ein Refresh, GPU rendert Frame 2, welches dann im VRAM liegt und startet dann mit Frame 3, welches natürlich ebenfalls in einen dritten Puffer geschrieben werden muß. Drei unterschiedliche Frames gleichzeitig irgendwo im Speicher. Triple Buffering.
:facepalm:

Deine Netzwerkkarte hat also Millionen Buffering, weil dein IP-Paket im RAM vom Server gespeichert wird, dann in der Netzwerkkarte, dann im Switch, dann im ....

Und das bringt Dir wieviele Nanosekunden? Bringt es überhaupt etwas?
Welchen Unterschied macht es, ob die Daten den Weg DP-Port=>Konversion auf LVDS=>Panel nehmen, oder GSYNC-Speicher=>Konversion auf LVDS=>Panel? ;)
Weil der LVDS deutlich performanter ist, als dei DP-Verbindung.

Das "Argument" kann man nur hanebüchen nennen. Was nutzt denn nV für GSync? Doch exakt die gleiche Sache (siehe Threadüberschrift).
Dein Argument gleicht in etwa dem, daß Räder ja wohl nicht das Richtige für ein Auto wären, da man damit doch im Mittelalter schon Kutschen betrieben hätte. :freak:
Ach? NVIDIA nutzt einfach nur Adaptive-Sync? Echt? Das ist deine Behauptung?

Du hattest doch gestern noch behauptet, G-Sync würde "gepollt" werden:

Es gab ja durchaus Berichte, nach denen es einen Handshake gibt, ob das GSync-Modul für ein neues Frame bereit ist, also die GPU praktisch Polling betreibt

Wo finde ich dieses "Polling" in der DP-Spec?

Du meinst die Kommunikation über DP? Da benutzt nV auch nichts, was wirklich dem Standard widerspricht und legt nur variable Pausen zwischen den Frames ein. Genau wie A-/FreeSync auch. Bidirektionale Kommunikation ist halt bei DP erlaubt. Falls GSync das für Handshakes zwischen GPU und Modul nutzt, ist das nicht unbedingt ein Vorteil oder "aufgebohrt", sondern größtenteils wohl konzeptionell unnötig und nur erforderlich, weil nVs Displayengines nicht direkt ASync-kompatibel sind, sprich eine externe Hilfe benötigen, um die Minimalrefreshrate einhalten zu können. Spricht etwas gegen diese Interpretation?
Ja, dass G-Sync FreeSync faktisch überlegen ist im status quo, das hatte ich ja bereits zu beginn gesagt. Bisher habe ich auch noch kein Indiz von dir gesehen, dass da irgendetwas von deinem obigen Absatz wahrscheinlich mach, noch, dass AMD morgen einen Wundertreiber bringt, der die Problematik umschifft.

Stattdessen behauptest du erst, G-Sync würde Polling betreiben, um dann zwei Posts weiter das völlige Gegenteil zu behaupten.

Bei A-/FreeSync teilt der Monitor mit, welchen Bereich an Refreshraten er unterstützt, dann sendet die GPU fröhlich drauflos und muß sich nur an die Grenzen halten. Bei GSync darf laut einigen Aussagen die GPU ständig beim Monitor nachfragen, ob er ein neues Frame akzeptieren kann (Polling, daher der leichte Performanceverlust). Mal abgesehen von den Implementationsunterschieden ist die Grafikkarte im variablen Bereich natürlich der Master, bei beiden.
Dass der Master (also im Falle G-Sync die GPU) mit einem Polling nachfragt, ob der Slave für eine Übertragung bereit ist, ist normale Aufbau einer Kommunikationsschnittstelle.

Bei FreeSync ist wählbar ob VSync außerhalb des variablen Bereiches an oder aus sein soll.
Unterhalb des VRR Bereiches ist FreeSync wie V-Sync bei AMD hart aus.

Was irgendwie gar kein Vorteil ist, wie schon festgestellt wurde.
Wenn man den Murks, den AMD unterhalb des Threshold produziert, nicht hat, würde ich das einen gewaltigen Vorteil nennen.

Die zeigt nur nicht das, was Troyan sagte.
Deshalb frage ich ihn ja :facepalm:

Kartenlehrling

2015-04-11, 12:33:32

Könnt ihr bitte das Zitat-Wall spamen lassen!!! , DANKE.

robbitop

2015-04-11, 12:41:40

Könnt ihr bitte das Zitat-Wall spamen lassen!!! , DANKE.

Ganz im Gegenteil. Die beiden sind zwei von sehr sehr wenigen hier im Forum, die dieses Thema so in dieser Tiefe verstehen. Wer das nicht lesen will, kann den Thread ja verlassen. Beiträge von solcher Tiefe sind wertvoller als irgendwelche 0815 Beiträge. Da gibt es die Möglichkeit ein paar Dinge zu lernen.

Es wäre aber schöner, wenn Dimitri seine Arroganz etwas herunterfahren kann und seinen Ton mäßigen würde. Eine technische Diskussion sollte immer sachlich sein - und nicht das Ziel haben, sein Gegenüber zu demütigen. Dann hat das keinen Sinn.

Grestorn

2015-04-11, 13:54:20

Die Argumentation von Dimitri erscheint mir nachvollziehbar und entspricht auch meiner Vorstellung.

Allerdings bin ich nicht so überzeugt, dass man das Verhalten nicht zumindest teilweise alleine im Treiber nachbilden kann und AMD somit weitestgehend aufschließen könnte. Auch wenn es logisch erscheint, dass ein lokaler Puffer im Monitor, aus dem das Refresh wenn nötig direkt bedient werden kann, mit hoher Wahrscheinlichkeit Vorteile hat.

Ansonsten hätte sich nVidia das auch sparen können.

Oder es ist doch so, wie ich schon vor einigen Posts vermutet habe, dass jeder Monitor im Scaler grundsätzlich einen Speicher für mindestens ein Frame, wenn nicht sogar mehr, hat. Die Speicherkosten dürften da kaum das Problem sein. Und einige der Funktionen eines Monitors lassen sich m.E. nur schwer oder sogar gar nicht ohne weiteres ohne Framebuffer umsetzen lassen.

fondness

2015-04-11, 13:59:37

Die Argumentation würde nur Sinn ergeben, wenn die Übertragung über das DP-Kabel der limitierende Faktor wäre, was offensichtlich nicht der Fall ist. Gipsel hat es mittlerweile eh schon mehrmals dargelegt und von der Gegenseite kommen eh nur noch Beleidigungen und Ausweichmanöver.

NV hätte sich das Modul natürlich sparen können, das tun sie ja sogar für Notebooks und wohl auch mittelfristig für Desktop aber ohne Modul gibt es G-Sync wohl frühestens ab Maxwell und man könnte nicht so schön die Konkurrenz ausschließen.

Schaffe89

2015-04-11, 14:28:27

Ganz im Gegenteil. Die beiden sind zwei von sehr sehr wenigen hier im Forum, die dieses Thema so in dieser Tiefe verstehen. .

Nur dass einer ein Troll ist und ein Nvidia Fanboy und der andere versucht ist vernünftig zu diskutieren.
Das bringt gar nichts.:rolleyes:

Die Argumentation von Dimitri erscheint mir nachvollziehbar und entspricht auch meiner Vorstellung.

Welche Aussage/Argumentation ist gemeint?

Weil der LVDS deutlich performanter ist, als dei DP-Verbindung.
Du meinst G-sync habe einen Vorteil, weil das Frame schon im G-syn Modul bereitsteht, anstatt dass es über den DP zum Monitor transportiert wird.
Das ist im Bereich der Nanosekunden.
Der Teil der Diskussion ist ziemlich absurd, imho um G-sync technisch hervorzuheben. Dagegen steht der deutlicher messbare Performancenachteil von G-sync.
Deswegen meine Aussage, wen Freesync das mit dem Sync unter der minimalen Refreshrate noch mit verdoppelung der Frames besser in den Griff kriegt, dann sehe ich hier eher die Vorteile auf der Freesyncseite, wenn auch nur minimal.
Es wäre ja schön wenn man glauben könnte, dass du wirklch wenigen technischer Dinge so einseiitg argumentierst, aber das hat sich mit deinen "Nvidia führt AMD vor" Stilblüten eigentlich schon erledigt gehabt.

robbitop

2015-04-11, 14:50:20

Nur dass einer ein Troll ist und ein Nvidia Fanboy und der andere versucht ist vernünftig zu diskutieren.
Das bringt gar nichts.:rolleyes:
Im Gegensatz zu den meisten anderen Beiträgen, haben seine Argumente (zumindest hier) echte Substanz.

Grestorn

2015-04-11, 15:22:49

Schaffe89

2015-04-11, 15:31:32

CPU, PCIe Bus (für das Kommando und Timing), die GPU, der Framebuffer in der GaKa, die DP Übertragung, der Scaler im Monitor und letztlich das Panel.

Nein, sind sie nicht. Bei dem Beispiel ging es nur um die Übertragung über den DP Anschluss im Vergleich zur übertragung aus dem Puffer zum Monitor.
Und das ist ja nicht stänidg so, sondern scheinbar nur in Ausnahmefällen, eben bei den zwischengespeicherten Frames.

Grestorn

2015-04-11, 15:33:49

Und wer initiiert die Übertragung? Richtig, der Treiber. Und welche Hardwarekomponente führt den Treiber aus? Richtig, die CPU. Und wie kommen die Kommandos des Treibers zur GPU? Richtig, über den PCIe Bus.

Alles potentielle Quellen von Latenzen. Vom DP selbst mal gar nicht zu reden.

fondness

2015-04-11, 16:13:11

Wir sprechen hier von 33 ms bis der gleiche Frame noch mal gesendet werden müsste wenn kein neuer fertig ist. Das sind Welten in der Kommunikation CPU/Treiber/PCIe, etc. wo man im Nanosekundenbereich operiert. Und der Framebuffer liegt ohnehin im VRAM der GPU vor. Aber okay es wird sich eh mittelfristig auflösen ob hier Vorteile bestehen bleiben oder nicht.

Grestorn

2015-04-11, 16:24:53

Na, ich würde ja mal sagen, dass Du das zu optimistisch siehst. Ein PC ist nun mal kein Echtzeitsystem. Und wenn auf Ereignisse reagiert werden muss, kann es immer Verzögerungen geben, die auch mal in den ms Bereich gehen.

Bei einer konstanten Wiederholrate (z.B. 60 Hz) läuft die Übertragung des Inhalts des aktiven Framebuffer über DP zum Monitor ganz von alleine, ohne zutun des Treibers. Das macht der DP Controller auf der GraKa von sich aus, so lange der Treiber keine andere Anweisung (z.B. Switch auf einen anderen Buffer) gibt. Nur deswegen läuft das auch so synchron und ohne Verzögerungen ab.

Aber jede Änderung des Verhaltens muss der Treiber anstoßen und steuern. Und solche Prozesse laufen beim PC eben nicht zuverlässig im ns Bereich ab. Zu viele Komponenten können da mit reinspucken.

Aber wie dem auch sei, nachweisen kann ich es nicht. Ich weiß nur, dass eine Ansteuerung aus dem internen Speicher des Scalers mit ziemlicher Sicherheit wesentlich unproblematischer ist, als das Ganze von der Grafikkarte aus über den DP zu machen. Ob sich das wirklich in der Praxis auswirkt, werden wir irgendwann erfahren.

Skysnake

2015-04-11, 16:53:24

Eine Übertragung aus einem lokalen Puffer wird immer effizienter und mit weniger Latenz vonstatten gehen, als eine Übertragung über eine externe Schnittstelle, bei der auch noch der Treiber der Grafikkarte mitspielen muss, d.h. es sind nahezu alle Komponenten involviert: CPU, PCIe Bus (für das Kommando und Timing), die GPU, der Framebuffer in der GaKa, die DP Übertragung, der Scaler im Monitor und letztlich das Panel.

So ein oller FPGA, wie da verbaut wurde, macht gerade mal einige dutzend/hundert MHz mit, dann ist schicht im Schacht. Man sollte nicht davon ausgehen, dass der FPGA mit deutlich mehr als 100-300MHz läuft auf dem GSync Modul.

Gipsel hat das schon alles richtig ausgeführt. Es macht so ziemlich keinen Unterschied, wo die Buffer genau sind. Die Panelelektronik ist nicht sonderlich schneller als die vom DP-Interface. Macht ja auch gar keinen Sinn....

Warum für die Panel Elektronik riesige Taktraten mitmachen, wenn der Input eh nichts derartiges bewerkstelligen kann.

Hier wird versucht irgendwelche Haarstreubenden Sachen zusammen zu reimen, dabei ist die ganze Sache eigentlich relativ einfach, wie von Gipsel schon mehrfach im Detail erleutert. Ich frage mich echt, warum man auf diese Auswüchse so anspringen kann

samm

2015-04-11, 16:58:01

Ich frage mich echt, warum man auf diese Auswüchse so anspringen kannWeil es eine Konkurrenz-Situation ist, und auf beiden Seiten merkliche Nachteile bestehen (Proprietäre Lösung seitens nVidia vs. Kinderkrankheit bei framerate unterhalb der VRR-Grenze seitens AMD) - Internet halt :)

robbitop

2015-04-11, 17:11:09

So ein oller FPGA, wie da verbaut wurde, macht gerade mal einige dutzend/hundert MHz mit, dann ist schicht im Schacht. Man sollte nicht davon ausgehen, dass der FPGA mit deutlich mehr als 100-300MHz läuft auf dem GSync Modul.

Angeblich ist mittlerweile ein ASIC verbaut.

fondness

2015-04-11, 17:14:08

Selbst dafür gibt es nicht den geringsten Beweis. Außerdem muss man sowieso kompatibel bleiben mit dem FPGA-Modul.

Gipsel

2015-04-11, 17:44:12

Nur leider tut das die GPU in dem Falle, über den wir hier reden, gar nicht mehr.Wir reden über die beiden Alternativen, die da wären es entweder von der GPU zu schicken oder aus dem lokalen Puffer zu lesen. :wink:
Du hast offensichtlich Triple Buffering nicht verstanden.Ich habe eine Beschreibung gepostet, die meine Version stützt. Du nicht. Also los, finde Belege, daß ich falsch liege!
Was sagt dir das Wort "überspringen"?Daß es fertig gerendert wird, Du es aber nicht anzeigen willst, weil ein neueres bereits fertig wurde. Dabei läufst Du aber genau in die von mir beschriebenen Probleme, wenn Du mal darüber nachdenkst.
Nein, im Gegenteil. Ich gebe zu, dass es den gemeinen Forenuser vllt überfordert, aber ich dachte hier wäre man Technikaffin?Na dann erkläre es doch mal!
Danke dafür, dass du selbst darlegst, dass G-Sync mitnichten Triple Buffering ist.

Wäre aber gar nicht notwendig gewesen :tongue:

Ja und hat leider null mit G-Sync zu tun.

Also ist es kein Triple Buffering, sondern 2+1. Danke.Es ist also 2+1=3fach Buffering? ;D
Danke für den Lacher.
Nur weil der eine Backbuffer zum Frontbuffer (auf dem GSYNC-Modul) kopiert wird (statt nur geflippt), ändert gar nichts daran. Zur Information, das Kopieren statt Flippen ist auch bei der GPU eine Option (Schau Dir mal an, wie man unter DX eine Swapchain konfiguriert!). Es hat halt einen gewissen Performancenachteil, aber ansonsten ändert das doch nichts.
:facepalm:

Deine Netzwerkkarte hat also Millionen Buffering, weil dein IP-Paket im RAM vom Server gespeichert wird, dann in der Netzwerkkarte, dann im Switch, dann im ....Ähm, Themenbezug? Der ist wohl nicht vorhanden.
Weil der LVDS deutlich performanter ist, als dei DP-Verbindung.Verlinke mir bitte eine FPD-Link-Spec, die das bestätigt (DP1.3 steht bei ~26Gbit/s netto) und zeige, daß das GSync-Modul dies nutzt. Zumal ist es einfach ein Fakt, daß die Panels die Daten schlicht nicht schneller entgegennehmen können. Kennt man doch vom Übertakten von Panels. Irgendwann geben entweder der FPD-Link zum Panel oder auch schlicht die Zeilen- und Spaltentreiber für die Pixelmatrix des Panels auf. Das limitiert, wie schnell man ein neues Bild zum Panel bekommt. Die maximale Refreshrate des Panels ist nahe des Maximums (ohne Übertaktung ist es das Maximum), wie schnell man die Daten da hin bekommt. Und das passiert meist, bevor man an die Bandbreitenlimits von DP kommt. ;)
Ach? NVIDIA nutzt einfach nur Adaptive-Sync? Echt? Das ist deine Behauptung?Vielleicht solltest Du mal genauer lesen, was ich geschrieben habe.
Du hattest doch gestern noch behauptet, G-Sync würde "gepollt" werden:

Wo finde ich dieses "Polling" in der DP-Spec?DP spezifiziert einen AUX Channel zur bidirektionalen Kommunikation zusätzlich zum Hauptlink. Was in diesen Paketen genau drinsteht und wozu es benutzt wird, kümmert die DP-Spec nicht, solange Sender und Empfänger was damit anfangen können. Seit DP1.2 hat das Ding ausreichend Bandbreite (afaik 720Mbit) um damit z.B. USB oder Netzwerkverbindungen darüber abzuwickeln. Gibt ja sogar eine Spec dafür, wie sich unterschiedliche Hersteller verstehen (Dockport), was hier natürlich unnötig ist. Aber für ein paar Synchronisationspakete reicht auch schon die für DP1.0 oder 1.1 spezifizierte Bandbreite. Und die garantierte Latenz sind übrigens 0,5ms. Hmm, interessante Zeitskale. Hatte ich die nicht schon mal erwähnt? ;)
Zusätzlich könnte das GSync-Modul noch über das HPD-Signal den Bedarf für das nächste Frame melden. Wie die GPU bzw. der Treiber das interpretiert, liegt ja nur an nVidia.
Ja, dass G-Sync FreeSync faktisch überlegen ist im status quo, das hatte ich ja bereits zu beginn gesagt. Bisher habe ich auch noch kein Indiz von dir gesehen, dass da irgendetwas von deinem obigen Absatz wahrscheinlich mach, noch, dass AMD morgen einen Wundertreiber bringt, der die Problematik umschifft.

Stattdessen behauptest du erst, G-Sync würde Polling betreiben, um dann zwei Posts weiter das völlige Gegenteil zu behaupten.:| Ich vermisse bei Dir ehrlich gesagt gerade etwas Textverständnis.
Dass der Master (also im Falle G-Sync die GPU) mit einem Polling nachfragt, ob der Slave für eine Übertragung bereit ist, ist normale Aufbau einer Kommunikationsschnittstelle.Und das passiert wohl immer, bei jedem Frame. Bei A-/FreeSync schiebt die GPU (Master) einfach einen Frame ohne Nachfrage und Handshake über externe Kanäle (der DP-Hauptlink ist unidirektional) rüber, der Monitor refreshed stumpf synchron bei jedem gelieferten Frame. Abgesprochen wird nur etwas beim Anstöpseln des Monitors (dessen Fähigkeiten).

==========================

Eine Übertragung aus einem lokalen Puffer wird immer effizienter und mit weniger Latenz vonstatten gehen, als eine Übertragung über eine externe Schnittstelle, bei der auch noch der Treiber der Grafikkarte mitspielen muss, d.h. es sind nahezu alle Komponenten involviert: CPU, PCIe Bus (für das Kommando und Timing), die GPU, der Framebuffer in der GaKa, die DP Übertragung, der Scaler im Monitor und letztlich das Panel.Da das Senden eines Frames von der GPU z.B. für einen Zwangsrefresh natürlich gepipelined wird (um auch die letzte µs Verzögerung zu eliminieren; man weiß ja vorher, wann genau die Bilddaten da sein müssen, fängt also entsprechend etwas vorher schon mit den Vorbereitungen an), verliert Latenz hier die Bedeutung. Der wichtige Punkt ist, kann man mit GSync auf dem Modul bessere Entscheidungen treffen, welches Frame darzustellen ist oder nicht? Die Antwort darauf lautet prinzipiell nein. Wenn das GSync-Modul weiß, daß kein neues Frame mehr rechtzeitig kommt, hat das notgedrungen die GPU um die Latenz der Übertragung früher gewußt. Man kann also exakt die gleiche Entscheidung treffen, weil einem die gleichen Informationen zur Verfügung stehen.
Bei GSync ist es eben nur der Scaler und das Panel. Ein FPGA / ASIC kann extrem schnell reagieren und agieren. Das ist schon ein Vorteil.Die GPU ist auch ein ASIC.
Und wer initiiert die Übertragung? Richtig, der Treiber. Und welche Hardwarekomponente führt den Treiber aus? Richtig, die CPU. Und wie kommen die Kommandos des Treibers zur GPU? Richtig, über den PCIe Bus.Die Übertragung wird nicht durch den Treiber initialisiert. Das macht die Displayengine in Hardware (wenn ein Timer abgelaufen ist, der auf die Refreshrate programmiert ist), da benötigt es keine Softwareintervention.
Wenn die Übertragung des alten Frames am Ende ankommt, löst die GPU einen Interrupt aus (bei Eintritt in die vblank-Phase). Wenn VSync an ist, wird in der dazugehörigen Interruptroutine das Kommando zum Bufferflip gegeben (die werden mit VSync solange zurückgehalten).
Die Bufferflips passieren also in Software, das Starten der Übertragung nicht.
Hmm, obwohl, bei GSync eventuell schon. Irgendwer muß ja noch offiziell bestätigen, wo genau der Performanceverlust herkommt, wie das mit dem Polling genau läuft und ob es da Softwareinteraktion per Treiber gibt oder nicht. Aber irgendwo kommt ja offensichtlich ein kleines Delay rein, was es bei FreeSync nicht gibt.

Unicous

2015-04-11, 20:08:42

Psychopat

2015-04-11, 20:14:05

Den Acer 34" 3440x1440 144 Hz IPS Monitor der vor ein paar Monaten durch TFTCentral geteasered wurde wird es wohl als FreeSync (899 Pfund) und G-Sync (999 Pfund) Variante geben.

http://forums.overclockers.co.uk/showpost.php?p=27897173&postcount=91

Darüber hinaus soll es 35" Versionen geben die auf VA basieren.

Die Version die ich gerne hätte wäre die mit G-Sync UND FreeSync. Darf dann auch gerne 1099 Pfund kosten. Aber warscheinlich wird nVidia das nicht erlauben...

fondness

2015-04-11, 20:14:19

Sieht so aus als hätten die Samsung 4K FreeSync-Monitore doch alle ein PLS-Panel:
https://twitter.com/pcmonitors/status/585870574980767744

/Edit: Allerdings nur 40hz-60hz Refresh Range wenn ich das richtig lese:

http://s1.postimg.org/ycef7h8wv/KY7_V6339.jpg (http://postimage.org/)

Hier gibt es bereits ein Handbuch:
http://fccid.net/document.php?id=2571995

aufkrawall

2015-04-11, 20:33:00

Gibts auch was mit 27/28"?

fondness

2015-04-11, 20:38:17

Ja, den UE590 wird es in 23,6 Zoll und 28 Zoll geben, den UE850 in 23,6 Zoll, 28 Zoll und 31,5 Zoll.

aufkrawall

2015-04-11, 20:41:50

Und wo entnimmst du, dass alle ein PLS-Panel haben sollen?

fondness

2015-04-11, 20:43:51

Es wäre zumindest seltsam wenn man die größeren Versionen mit einem billigeren Panel ausstattet. Vorausgesetzt natürlich der tweet oben ist korrekt.

aufkrawall

2015-04-11, 20:47:05

Warum wurden sie dann erst anders angekündigt?
Und warum kann man sie noch nicht kaufen, Release sollte doch im März sein?
Too many Fragen... :freak:

Wär ja schön, aber ich glaubs erst, wenn ichs sehe.
Falls zutreffend, könnte aber Fiji auf einmal wieder interessant werden.

Bei den eingeschränkten Refreshraten wäre mal um so wichtiger, dass AMD eine Treiber-Lösung für diese findet.

fondness

2015-04-11, 20:54:26

Warum man sie noch nicht kaufen kann ka, scheint offenbar üblich zu sein das sich Monitore verschieben^^
Aber das mit der Info TN-Panel kam AFAIK nur von Heise und war alles andere als offiziell.

samm

2015-04-11, 21:22:52

Das Handbuch für den UE590 irritiert mich... der Bereich der refreshrates für DP ist das eine, und dass Freesync nur auf den 24"-Modellen explizit supported wird, wenn man der Kapitelüberschrift und dem pcmonitors-Tweet exklusive Wahrheit unterstellt.

Eigentlich wartete ich ja v.a. auf vertrauenswürdige in-depth-Reviews des Asus-Teils, aber nun klingen die Acers doch auch super: 34" IPS, 3440x1440 @ 144Hz, und dann auch noch 35" VA Varianten :eek: (wobei "dank" 21:9 immer noch nur minimal mehr vertikale Bildfläche als mein alter 16:10 24", grmpf) Termin erst im August, d.h. vielleicht bis Ende Jahr mal getestet und hier verfügbar *seufz*

Unicous

2015-04-11, 21:24:48

Die Acer Specs mögen "super" klingen, am Ende ist es dennoch...Acer.

Was du mit explizit nur auf den 24" Modellen supported meinst verstehe ich im Übrigen nicht. Samsung hatte 5 Monitore mit Freesync vorgestellt. Die werden auch kommen.

fondness

2015-04-11, 21:25:50

Wenn diese Panels verfügbar sind werden entsprechende Monitore mit hoher Wahrscheinlichkeit nicht nur noch Acer kommen.

samm

2015-04-11, 21:27:37

Weiss nicht, ob Acer für mich so schlimm wäre - bisher habe ich keine Erfahrungen mit der Marke, und es ist mir egal, wenn ihre Billigprodukte verschrieen sind, denn es geht bei diesen Monitoren wohl eher um High-End-Produkte.

Unicous

2015-04-11, 21:32:03

@fondness

Auch Acer wäre wie Asus in der Lage spezielle Panels herstellen zu lassen, siehe ROG Swift.

Von daher, abwarten. Dass LG jetzt erst mit 144 Hz IPS Panels kommt die bei 27" aber nur eine Auflösung von 1080p haben dürfte auch eher traurig stimmen.
Das einzig interessante sind die A-TW ("Advanced True White":rolleyes:) Polarizer-Folien um den "glow" zu mindern.

http://www.tftcentral.co.uk/news_archive/33.htm#lg.display_panels

@samm

Ich würde mir schon allein keinen Acer kaufen, weil sie aussehen wie Plastikbomber. Die Klavierlack-Optik geht gar nicht und Fingerabdrücke noch weniger.

samm

2015-04-11, 21:44:21

Ist der Plastikbomber-Look denn bei allen Acers der Fall? Bei meinen sonst eingesetzten Asus- und BenQ-Bildschirmen gibt es je nach Preislage und Zielpublikum beide Varianten.

Grestorn

2015-04-11, 22:40:22

Die Übertragung wird nicht durch den Treiber initialisiert. Das macht die Displayengine in Hardware (wenn ein Timer abgelaufen ist, der auf die Refreshrate programmiert ist), da benötigt es keine Softwareintervention.Bei einer festen Refreshrate: Ja, das habe ich ja selbst geschrieben.

Aber im Falle eines eingeschobenen Wiederholframes geht das mit ziemlicher Sicherheit nicht, da wird schon der Treiber manuell eingreifen müssen. Ebenso wenn ein Buffer-Switch stattfindet und deswegen ein expliziter Refresh des Monitors ausgelöst wird - das ist dann bei GSync aber auch nicht anders. Nur bei den Wiederholframes sehe ich einen Vorteil, wenn es bei GSync vollständig im Monitor stattfinden kann, denn da wäre die GPU und der DP dann sicher nicht beteiligt sein.

Kartenlehrling

2015-04-11, 22:44:58

..., Release sollte doch im März sein?
Too many Fragen... :freak:

Samsung hat nie etwas von März gesagt .... Anfang Mai .

Unicous

2015-04-11, 23:08:16

Samsung hat nie etwas von Mai gesagt... ab März.

Du kannst ja gerne deine Quellen angeben die Mai behaupten. Samsung hat von März gesprochen.

Samsung to release first displays with AMD FreeSync technology next March (http://www.kitguru.net/components/graphic-cards/anton-shilov/samsung-to-release-its-first-displays-with-amd-freesync-technology-next-march/)

Kartenlehrling

2015-04-11, 23:38:37

Bringen Sie Ihre Unterhaltung auf ein neues Niveau in Sachen Erlebnis und Komfort
• AMD FreeSync: Synchronisiert die Bildschirmaktualisierungsrate dynamisch mit der Bildrate Ihres Inhalts, um Eingangslatenz zu minimieren und Stottern und Verzögern während des Spielens und der Videowiedergabe dramatisch zu reduzieren.
• Aktualisierter HDMI-Support: Mit einer aktualisierten HDMI, die UHD-Auflösungen bei einer Aktualisierungsrate von 60 Hz unterstützt, werden 4K-Inhalte flüssig und ohne Verzögerung abgespielt, selbst wenn der Anschluss über AV-Geräte erfolgt.
• Spiel-Modus: Passen Sie Ihre Bildschirmeinstellungen für ein optimiertes Spielerlebnis ganz schnell auf dem Bildschirm an. Der Spiel-Modus verbessert die Dunkelheit des Bildes, so dass Sie die Action hautnah erleben.
• Schnelle Ansprechzeit von 1 ms: Verfolgen Sie selbst die schnellste Bewegung auf dem Bildschirm ohne Bewegungsunschärfe, Ruckeln oder Geisterbilder.

LCD Technologie A-si TFT/TN

Also der Samsung 28" E590 ist ein TN mit 60Hz, Quelle weiss nicht nicht mehr, so ein Manager von Samung in Nadelstreifen.

aufkrawall

2015-04-12, 00:45:03

Das 144Hz AHVA-Panel hat auch defakto TN-Reaktionszeiten.
Könnte Marketing-Geblubber sein.

Skysnake

2015-04-12, 08:40:01

Grestorn

2015-04-12, 09:12:46

Warum sollte man etwas mit dem GSync FPGA lösen können, was nicht auch die GPUs native machen können?

Alles was du brauchst sinst ein paar Counter und ne finite State machine. Das ist absolut nichts, was eine überragende komplexität hat. Das einzige "Problem" ist halt, das man die Funktionalität in der Hardware drin haben muss. Entweder man hat es drin/dran gedacht, oder eben nicht. Den Treiber brauchste aber für so simple Sachen nicht. Die dafür nötige Hardware ist lächerlich klein.

Weil man das GSync FPGA entsprechend programmieren kann. Natürlich kann man auch die DP Controller in den GPUs theoretisch entsprechend funktional erweitern, aber ehrlich gesagt bezweifle ich, dass man das getan hat. Wäre dem so, dann würde es ja auch funktionieren. Tut es aber derzeit bekanntermaßen nicht.

myMind

2015-04-12, 10:18:05

Warum sollte man etwas mit dem GSync FPGA lösen können, was nicht auch die GPUs native machen können?

Alles was du brauchst sinst ein paar Counter und ne finite State machine. Das ist absolut nichts, was eine überragende komplexität hat. Das einzige "Problem" ist halt, das man die Funktionalität in der Hardware drin haben muss. Entweder man hat es drin/dran gedacht, oder eben nicht. Den Treiber brauchste aber für so simple Sachen nicht. Die dafür nötige Hardware ist lächerlich klein.
Ist denn schon geklärt, wofür die 768MB Speicher auf dem G-Sync-Modul verwendet werden? Die Diskussion mit dem Tripplebuffer ist ja schön und gut, aber für genau einen Buffer bräuchte man keine 768MB.

Es wurde hier einiges über die Bandbreite von DP gesagt, aber nichts über die Latenzen (z.B. Wandler).

Skysnake

2015-04-12, 11:58:16

Die Latenzen kannste in der Pfeife rauchen....

Ansonsten die 768MB brauchste allein schon um die volle SI-Bandbreite zu haben. Ganz abgesehen davon, das man bei FPGAs meist keine sonderlich große Auswahl hat, was an Speicher gut funktioniert mit den FPGAs

Dimitri Mayakovsky

2015-04-12, 13:53:00

NV hätte sich das Modul natürlich sparen können
Der Teil der Diskussion ist ziemlich absurd, imho um G-sync technisch hervorzuheben. Dagegen steht der deutlicher messbare Performancenachteil von G-sync.
Solange FreeSync im Bereich unterhalb der minimalen Refreshrate auf einen VSync-Off Modus wechselt ist G-Sync technisch überlegen. Punkt.

Weder haben wir eine Bestätigung von AMD, dass es ein Bug ist, noch, dass es jemals dafür einen Fix gibt. Es ist einfach nur eine Behauptung von Gipsel, für die er bisher jedes Indiz verweigert hat.

Und solange Monitor mit einer minimalen Refreshrate von 40 Hz verkauft werden, ist dies der Knackpunkt, an dem FreeSync gegenüber G-Sync schlicht ein Witz ist.

Schaffe89

2015-04-12, 13:57:14

Und wenn es diesen Unterschied zwischen Freesync und G-sync nicht gebe, fiele dir ein andere Punkt ein warum Freesync ein Witz ist.
144 Hertz Monitore die einen Range von 40 bis 144 Hertz anbieten, dürften im Vergleich zu G-sync sicherlich kein "Witz" sein.
Und da Freesync in den ersten Tests recht gut funktioniert hat, lässt sich das objektiv sicherlich anders bewerten, als wie du das machst.

aufkrawall

2015-04-12, 13:58:59

Die nicht, aber wenn ich mir in 4k um Ekel-Tearing und Ekel-Lag bei niedrigen fps keine Sorgen mehr machen muss, ist das schon ein großer Vorteil.

dargo

2015-04-12, 14:01:56

Den Ekel-Lag hast du schon lange bei mehr als 25ms.

aufkrawall

2015-04-12, 14:04:35

Kauf dir einen gescheiten Monitor ohne Lag. Mit dem Frostbite-Limiter treff ich hier selbst mit 75Hz 30fps was...

Dimitri Mayakovsky

2015-04-12, 14:07:59

Wir reden über die beiden Alternativen, die da wären es entweder von der GPU zu schicken oder aus dem lokalen Puffer zu lesen. :wink:
Nein, wir reden über die Unterschiede in der Übertragung zwischen GPU und Scaler. Als du dort mit deiner Argumentation vor die Wand gefahren bist, hast du schnell versucht auf die Übertragung zwischen Scaler und Panel zu wechseln.

Hab ich nur leider bemerkt.

Ich habe eine Beschreibung gepostet, die meine Version stützt. Du nicht. Also los, finde Belege, daß ich falsch liege!
Leider sagt nur dein eigener Text das Gegenteil aus ;)

Daß es fertig gerendert wird, Du es aber nicht anzeigen willst, weil ein neueres bereits fertig wurde. Dabei läufst Du aber genau in die von mir beschriebenen Probleme, wenn Du mal darüber nachdenkst.
Dann hast du es offensichtlich erst jetzt verstanden, denn im letzten Posting hast du irgendwas von einer Refreshrate oberhalb der maximalen Refreshrate des Panels gefaselt - darum ging es nur schlicht nicht.

Na dann erkläre es doch mal!
Das habe ich bereits 4x. Ich glaube nicht, dass es jetzt beim 5. Mal bei dir plötzlich Klick macht.

Es ist also 2+1=3fach Buffering? ;D
Danke für den Lacher.
Nein, es ist Double Buffering. Mit einem extra Speicher im Monitor. Was völlig Anderes als Triple Buffering.

Nur weil der eine Backbuffer zum Frontbuffer (auf dem GSYNC-Modul) kopiert wird (statt nur geflippt), ändert gar nichts daran. Zur Information, das Kopieren statt Flippen ist auch bei der GPU eine Option (Schau Dir mal an, wie man unter DX eine Swapchain konfiguriert!). Es hat halt einen gewissen Performancenachteil, aber ansonsten ändert das doch nichts.
Es ist nur etwas völlig Anderes, ob ich einen Buffer innerhalb des Framebuffers der GPU kopiere (bzw. den Pointer ändere), oder ob ich das Frame zunächst über einen DisplayLink schicke und dann im Monitor speichere.

Dein eigenes Zitat besagt ja, wie von mir markiert, "a programm". Einzahl. Bei einem Tandem aus GPU+Monitor, verbunden über DP kannst du kaum von "a programm" sprechen.

Ähm, Themenbezug? Der ist wohl nicht vorhanden.
Ich habe dir versucht obigen Bullshit, den du verzapft hast, anhand eines anderen Beispiels zu erklären. War wohl leider zu kompliziert.

Verlinke mir bitte eine FPD-Link-Spec, die das bestätigt (DP1.3 steht bei ~26Gbit/s netto) und zeige, daß das GSync-Modul dies nutzt. Zumal ist es einfach ein Fakt, daß die Panels die Daten schlicht nicht schneller entgegennehmen können. Kennt man doch vom Übertakten von Panels. Irgendwann geben entweder der FPD-Link zum Panel oder auch schlicht die Zeilen- und Spaltentreiber für die Pixelmatrix des Panels auf. Das limitiert, wie schnell man ein neues Bild zum Panel bekommt. Die maximale Refreshrate des Panels ist nahe des Maximums (ohne Übertaktung ist es das Maximum), wie schnell man die Daten da hin bekommt. Und das passiert meist, bevor man an die Bandbreitenlimits von DP kommt. ;)
Es geht nicht um die Bandbreite, sondern um die Latenz. Das hätte ich vllt besser ausdrücken sollen, da hast du Recht, da war Performance zu allgemein.

Vielleicht solltest Du mal genauer lesen, was ich geschrieben habe.
Gern nochmal das Zitat, wo du offensichtlich vergessen hast, was du selbst geschrieben hast:
Was nutzt denn nV für GSync? Doch exakt die gleiche Sache (siehe Threadüberschrift).
Was behauptest du damit sonst, als dass G-Sync exakt Adaptive Sync ist?

DP spezifiziert einen AUX Channel zur bidirektionalen Kommunikation zusätzlich zum Hauptlink. Was in diesen Paketen genau drinsteht und wozu es benutzt wird, kümmert die DP-Spec nicht, solange Sender und Empfänger was damit anfangen können. Seit DP1.2 hat das Ding ausreichend Bandbreite (afaik 720Mbit) um damit z.B. USB oder Netzwerkverbindungen darüber abzuwickeln. Gibt ja sogar eine Spec dafür, wie sich unterschiedliche Hersteller verstehen (Dockport), was hier natürlich unnötig ist. Aber für ein paar Synchronisationspakete reicht auch schon die für DP1.0 oder 1.1 spezifizierte Bandbreite. Und die garantierte Latenz sind übrigens 0,5ms. Hmm, interessante Zeitskale. Hatte ich die nicht schon mal erwähnt? ;)
Zusätzlich könnte das GSync-Modul noch über das HPD-Signal den Bedarf für das nächste Frame melden. Wie die GPU bzw. der Treiber das interpretiert, liegt ja nur an nVidia.
Also verstehe ich dich jetzt richtig und jetzt behauptest du das völlige Gegenteil von obiger Behauptung "exakt gleich"?

Was denn nun? Möchtest du dich nicht mal langsam entscheiden?
[/QUOTE]

:| Ich vermisse bei Dir ehrlich gesagt gerade etwas Textverständnis.
Weil du meine Aussage von Anfang an nicht verstanden hast? :confused:

Und das passiert wohl immer, bei jedem Frame. Bei A-/FreeSync schiebt die GPU (Master) einfach einen Frame ohne Nachfrage und Handshake über externe Kanäle (der DP-Hauptlink ist unidirektional) rüber, der Monitor refreshed stumpf synchron bei jedem gelieferten Frame. Abgesprochen wird nur etwas beim Anstöpseln des Monitors (dessen Fähigkeiten).
Ach jetzt ist FreeSync ja doch was völlig anderes als G-Sync, denn jetzt fehlt ja das Polling :freak:

Gipsel

2015-04-12, 14:09:21

Bei einer festen Refreshrate: Ja, das habe ich ja selbst geschrieben.

Aber im Falle eines eingeschobenen Wiederholframes geht das mit ziemlicher Sicherheit nicht, da wird schon der Treiber manuell eingreifen müssen. Ebenso wenn ein Buffer-Switch stattfindet und deswegen ein expliziter Refresh des Monitors ausgelöst wird - das ist dann bei GSync aber auch nicht anders. Nur bei den Wiederholframes sehe ich einen Vorteil, wenn es bei GSync vollständig im Monitor stattfinden kann, denn da wäre die GPU und der DP dann sicher nicht beteiligt sein.Skysnake hat eigentlich das eigentlich schon beantwortet. Ich stimme ihm da voll zu. Natürlich kann das in Hardware gemacht werden (auch die wiederholten Frames). Wenn man eine Displayengine dafür auslegt, wäre es bescheuert die Handvoll Transistoren nicht zu investieren. Der Aufwand ist wirklich lächerlich gering. Was glaubst Du denn, warum die dynamischen Refreshraten bei den Radeons erst ab Bonaire gehen?
Und die Programmierbarkeit? Wenn Du zwei oder drei verschiedenen Verhaltensweisen ein wenig konfigurieren kannst, reicht das doch völlig aus. Wir reden hier ja von einer Sache, deren Ziel sehr klar ist. Daß der FPGA im GSync-Modul auch Bitcoin-Mining machen könnte (weiß gar nicht, ob der dazu groß genug ist), hilft ihm dafür nicht wirklich ;). Und wenn Dimitri recht hat, dann ist in den neueren Monitoren bereits ein ASIC drin (hat den schon mal einer gesehen?), dann war's das vermutlich auch mit der freien Programmierbarkeit.

Und auf einer allgemeineren Ebene, selbst wenn AMD irgendwas an der Implementation verbaselt haben sollte, ist das kein Argument dafür oder dagegen, was mit ASync geht und was nicht. Prinzipiell brauchst Du das GSync-Modul nicht.

fondness

2015-04-12, 14:28:41

Die nicht, aber wenn ich mir in 4k um Ekel-Tearing und Ekel-Lag bei niedrigen fps keine Sorgen mehr machen muss, ist das schon ein großer Vorteil.

Bei einem Monitor mit max 60hz Refreshrate kann man das ohnehin vergessen, auch mit Frameverdoppelung.

aufkrawall

2015-04-12, 14:30:46

Bei einem Monitor mit max 60hz Refreshrate kann man das ohnehin vergessen, auch mit Frameverdoppelung.
Abwarten, dieses Verhalten ist afair noch gar nicht untersucht worden. 4k Gsync gibts ja schon, muss nur mal jemand machen.

fondness

2015-04-12, 14:32:24

Da gibt es nicht viel zu untersuchen IMO, wenn der Monitor nicht schneller als mit 60 hz refreshen kann hast du durch Frameverdoppelung unvermeidbar bei einer signifikanten Anzahl an Frames einen Lag drinnen. Statistisch betrachtet bei jedem zweiten.

Dimitri Mayakovsky

2015-04-12, 14:32:50

Bei einem Monitor mit max 60hz Refreshrate kann man das ohnehin vergessen, auch mit Frameverdoppelung.
Warum?

robbitop

2015-04-12, 14:35:25

Weil der Zwangsrefresh (fps < 30 - bzw nach neusten Erkennnissen ja 36 fps) 16 ms statt 7 ms dauert. Das kann schon einen Unterschied ausmachen.

fondness

2015-04-12, 14:37:59

Warum?

Weil der Monitor dann ~17ms benötigt um ein neues Bild darzustellen. Das G-Sync-Modul muss aber nach spätestens 33ms das Bild refreshen. Statistisch betrachtet hast du damit bei jedem zweiten Frame unter der minimalen Syncrate eine Kollisionen und der neuen Frame muss warten bis der Verdoppelung des alten abgeschlossen ist. Ich kann mir nicht vorstellen dass das dann noch gut aussieht wenn man bei jedem zweiten Bild ein Delay drinnen hat -> µRuckeln durch die Frameverdoppelung bei ohnehin schon niedrigen fps. Da ist es dann wohl sogar besser man spielt ohne Frameverdoppelung.

Dimitri Mayakovsky

2015-04-12, 14:38:35

Weil der Zwangsrefresh (fps < 30 - bzw nach neusten Erkennnissen ja 36 fps) 16 ms statt 7 ms dauert. Das kann schon einen Unterschied ausmachen.
Zumindest muss das Panel einen niedrigeren unteren Threshold haben, denn Framedoubling bei 35 Hz klappt mit maximal 60 Hz gar nicht.

fondness

2015-04-12, 14:42:20

Zumindest muss das Panel einen niedrigeren unteren Threshold haben, denn Framedoubling bei 35 Hz klappt mit maximal 60 Hz gar nicht.

Natürlich würde es auch mit 35hz gehen, aber halt noch schlechter.

Wenn das Framedoubling bei einer 60Hz Monitor ordentlich funktionieren soll braucht es wohl mindestens 20Hz als untere Sync-Grenze und da kann man es sich dann auch gleich sparen da unter 20fps ohnehin nicht mehr spielbar ist.

aufkrawall

2015-04-12, 14:48:07

Weil der Zwangsrefresh (fps < 30 - bzw nach neusten Erkennnissen ja 36 fps) 16 ms statt 7 ms dauert. Das kann schon einen Unterschied ausmachen.
Eine Unregelmäßigkeit von 7ms würde man vermutlich auch bemerken. Laut Pcper und Gsync-User tut man das aber nicht. Und hängt die maximale Refreshrate intern wirklich sklavisch an DP?

fondness

2015-04-12, 14:50:20

Eine Unregelmäßigkeit von 7ms würde man vermutlich auch bemerken. Laut Pcper und Gsync-User tut man das aber nicht. Und hängt die maximale Refreshrate intern wirklich sklavisch an DP?

Bei 144Hz Monitoren tritt diese "Unregelmäßigkeit" von 1-7ms auch viel seltener auf wie bei 60Hz Monitoren die 1-16,6ms Verzögerung.

aufkrawall

2015-04-12, 14:55:11

Eigentlich müsste man das auch ganz einfach mit einem 144Hz Monitor testen können, indem man einfach die maximale Refreshrate begrenzt.

robbitop

2015-04-12, 14:55:54

@fondness
Eben. Und das merkt man wirklich wirklich schwierig. 1...7ms ist schon recht wenig.

Grestorn

2015-04-12, 15:03:51

Skysnake hat eigentlich das eigentlich schon beantwortet. Ich stimme ihm da voll zu. Natürlich kann das in Hardware gemacht werden (auch die wiederholten Frames). Wenn man eine Displayengine dafür auslegt, wäre es bescheuert die Handvoll Transistoren nicht zu investieren. Der Aufwand ist wirklich lächerlich gering. Was glaubst Du denn, warum die dynamischen Refreshraten bei den Radeons erst ab Bonaire gehen?

Natürlich KANN man das machen. Das habe ich nie bezweifelt. Die Frage ist: WURDE das gemacht. In der aktuellen Generation aller Grafikkarten bezweifle ich das stark.

Und ehrlich gesagt: Ich glaube auch nicht, dass das kommen wird (eine Implementierung in der DP Controller Hardware). Aber lassen wir uns überraschen.

Weil der Monitor dann ~17ms benötigt um ein neues Bild darzustellen. Das G-Sync-Modul muss aber nach spätestens 33ms das Bild refreshen. Statistisch betrachtet hast du damit bei jedem zweiten Frame unter der minimalen Syncrate eine Kollisionen und der neuen Frame muss warten bis der Verdoppelung des alten abgeschlossen ist. Ich kann mir nicht vorstellen dass das dann noch gut aussieht wenn man bei jedem zweiten Bild ein Delay drinnen hat -> µRuckeln durch die Frameverdoppelung bei ohnehin schon niedrigen fps. Da ist es dann wohl sogar besser man spielt ohne Frameverdoppelung.

Das bezweifle ich sehr stark. Denn dann hast Du Tearing oder eine feste Framerate von 40 fps (wie VSync bei 40 Hz). Beides ist echt Scheiße. Dagegen hat noch niemand optisch den Judder-Effekt durch Kollisionen der Wiederholframes nachgewiesen, darüber reden wir nur rein theoretisch.

Ich finde es schon bemerkenswert, wie ein momentaner Vorteil gerade möglichst kleingeredet wird. Warum kann man das nicht einfach mal stehen lassen und hoffen, dass AMD das so schnell wie möglich nachliefern kann? Es ist einfach sinnvoll!

aufkrawall

2015-04-12, 15:10:39

Grestorn, man kann doch sicherlich auch mit Gsync einfach die maximale Refreshrate in den Spielen auswählen wie bisher.
Magst du auch mal mit maximal 60Hz niedrige fps testen?

Grestorn

2015-04-12, 15:17:54

Grestorn, man kann doch sicherlich auch mit Gsync einfach die maximale Refreshrate in den Spielen auswählen wie bisher.
Magst du auch mal mit maximal 60Hz niedrige fps testen?

Wenn das Spiel es zulässt, die Framerate einzustellen, dann richtet sich der Monitor schon danach.

Aber warum sollte der Monitor in einem 60 Hz Mode trotzdem länger als 7ms für einen Refresh brauchen? Der Refresh hängt doch nicht vom Displaymodus ab sondern davon, wie schnell das Panel und der Scaler ist.

Ich gehe davon aus, dass es beim Swift immer 7ms sind, egal welcher Modus läuft. Alles andere wäre sinnbefreit.

Gipsel

2015-04-12, 15:36:20

Langsam wird es ermüdend. Willst Du es nicht verstehen?
Nein, wir reden über die Unterschiede in der Übertragung zwischen GPU und Scaler. Als du dort mit deiner Argumentation vor die Wand gefahren bist, hast du schnell versucht auf die Übertragung zwischen Scaler und Panel zu wechseln.

Hab ich nur leider bemerkt.Du liegst falsch. Lies die alten Post! Flipflopping kannst Du mir sicherlich nicht vorwerfen. Du verstehst nur nicht, wo die Bottlenecks liegen und hast die an anderen Stellen verortet, auf die ich dann eingegangen bin. Wenn Dir das nicht aufgegangen ist, bezweifle ich langsam, daß das hier was bringt.
Leider sagt nur dein eigener Text das Gegenteil aus ;)Ähm, nein. Ich habe für Dich sogar extra den Teil mit den übersprungenen Frames gefettet. Soll ich den englischen Text für Dich übersetzen? Mache ich gerne, wenn es dem Verständnis hilft.
Dann hast du es offensichtlich erst jetzt verstanden, denn im letzten Posting hast du irgendwas von einer Refreshrate oberhalb der maximalen Refreshrate des Panels gefaselt - darum ging es nur schlicht nicht.Du siehst offenbar die Implikationen nicht. Also mal ganz langsam, damit das alle verstehen.
Du willst, daß während einem Refresh (der 1/Maximalrefreshrate dauert) zwei Frames fertig werden. Daß geht nur, wenn die Frametime für den zweiten Frame kleiner ist, als die Dauer des Refreshes. Was man gemeinhin auch so ausdrückt, daß die Framerate über der Refreshrate liegt(das sind schlicht die Kehrwerte).
Und dann treten genau die Probleme bei dem von Dir aufgestelltem Szenario auf, die ich beschrieben habe.
Das habe ich bereits 4x. Ich glaube nicht, dass es jetzt beim 5. Mal bei dir plötzlich Klick macht.Du verbrämst Deine (falsche) "Erklärung" von Triple Buffering. Ich habe einen Link angeboten (was offenbar vergebene Liebesmüh war), Du nicht. Du kommst dann mit sowas:
Tripe Buffering ist statisch, G-Sync ist ein Können, im Sinne von: Altes Frame nehmen, wenn sonst nix da ist.Das ist schlicht Blödsinn und ziemlich belanglos, weil es keine Eigenart von GSync ist oder sonstwas. Genau das tun GPUs schon seit es GPUs gibt. Wenn zum Beginn eines Refreshzyklus kein neues Frame da ist, wird mit dem alten refreshed. Das sind die Basics, über die man kaum reden müssen sollte. Du scheiterst offenbar daran, das Wesentliche zu erkennen.
Nein, es ist Double Buffering. Mit einem extra Speicher im Monitor. Was völlig Anderes als Triple Buffering.Double Buffering mit drei verschiedenen Frames in drei verschiedenen Puffern. Glaubst Du das wirklich? :freak:
Es ist nur etwas völlig Anderes, ob ich einen Buffer innerhalb des Framebuffers der GPU kopiere (bzw. den Pointer ändere), oder ob ich das Frame zunächst über einen DisplayLink schicke und dann im Monitor speichere.Was ist daran völlig anders, wenn ich beide Male einen Puffer von einem Ort an einen anderen kopiere? Daß die physisch etwas weiter separiert sind, als die Speicherchips auf der Grafikkarte? Toller Unterschied! Konzeptionell ist es keiner.
Dein eigenes Zitat besagt ja, wie von mir markiert, "a programm". Einzahl. Bei einem Tandem aus GPU+Monitor, verbunden über DP kannst du kaum von "a programm" sprechen.:freak: Ein wenig Abstraktion kann manchmal helfen.
Das Programm (z.B. ein Spiel) rendert in einen Puffer. Wenn sie fertig ist, signalisiert sie das und macht dann (nach eventuell verordneter Wartezeit, weil gerade kein Puffer frei ist) mit einem (meist anderen) Puffer weiter. Die Anwendung kümmert in diesem Zusammenhang nicht, wie das Betriebssystem, der Treiber oder die Grafikkarte oder im Zweifelsfall der Monitor das genau handhaben. Das ist völlig unerheblich, wie das konkret implementiert ist. Wichtig ist, daß am Ende bei Deinem Szenario effektiv Triple Buffering rauskommt. Das von Dir vorgeschlagene Verhalten ist nämlich genau das.
Ich habe dir versucht obigen Bullshit, den du verzapft hast, anhand eines anderen Beispiels zu erklären. War wohl leider zu kompliziert.Nein, es hat nur nichts mit dem Thema zu tun. Du weigerst Dich, die Puffer zu zählen und deren Funktionalität zu erkennen. Komm schon! 1,2,3. Das ist nicht so schwer. ;)
Es geht nicht um die Bandbreite, sondern um die Latenz. Das hätte ich vllt besser ausdrücken sollen, da hast du Recht, da war Performance zu allgemein.Latenz der Kommunikation zum Panel? Da schickt man nur was hin und die Übertragungsdauer ist weder von GSync noch von FreeSync beeinflußbar. Man muß arbeiten, mit dem was da ist. Bei beiden müssen die Daten letztendlich irgendwie zum Panel. Das ist schlicht kein Unterschied zwischen beiden Varianten (außer daß ASync natürlich nicht nur mit FPD-Links funktioniert).
Gern nochmal das Zitat, wo du offensichtlich vergessen hast, was du selbst geschrieben hast:

Was behauptest du damit sonst, als dass G-Sync exakt Adaptive Sync ist?
Der feine Unterschied zwischen das Gleiche zu nutzen, um einen bestimmten Effekt zu erzielen und das Gleiche zu sein, ist Dir sicherlich nur versehentlich entgangen. Die Unterscheidung meinerseits war nicht versehentlich. Die Umsetzung, also wie man es genau nutzt, unterscheidet sich natürlich schon etwas.
Weil du meine Aussage von Anfang an nicht verstanden hast? :confused:Weil Du mir Aussagen unterstellst, die ich nicht getätigt habe.

aufkrawall

2015-04-12, 15:37:24

Muss ich wohl mal zu Overclock.net o.ä. rüber und nach jemandem mit dem Acer XB280HK fragen.

Gipsel

2015-04-12, 15:43:17

Und hängt die maximale Refreshrate intern wirklich sklavisch an DP?Das hängt am maximalen Refresh des Panels.

Gipsel

2015-04-12, 15:47:39

@Dimitri:

Um mal diese Zitate einzudämmen, ganz kurz und knapp ein Angebot.
Was ist Dir unklar? Ich erkläre es Dir.
Ich bitte um eine kompakte Antwort.

fondness

2015-04-12, 16:10:10

Das bezweifle ich sehr stark. Denn dann hast Du Tearing oder eine feste Framerate von 40 fps (wie VSync bei 40 Hz). Beides ist echt Scheiße. Dagegen hat noch niemand optisch den Judder-Effekt durch Kollisionen der Wiederholframes nachgewiesen, darüber reden wir nur rein theoretisch.

Natürlich gehört es untersucht, mich würde ja alleine schon interessieren ob NV das Framedoubeling bei 60Hz Monitoren überhaupt noch macht. Gibt ja aktuell - vielleicht auch nicht ohne Grund - nur einen einzigen 60Hz G-Sync-Monitor, während bereits zahlreiche 60 oder 75Hz FreeSync-Monitore angekündigt wurden. Aber das sich bei solchen Monitoren der Jitter durch Framdoubeling erheblich verstärkt sollte offensichtlich sein.

Ich finde es schon bemerkenswert, wie ein momentaner Vorteil gerade möglichst kleingeredet wird. Warum kann man das nicht einfach mal stehen lassen und hoffen, dass AMD das so schnell wie möglich nachliefern kann? Es ist einfach sinnvoll!

Gar nichts wird kleingeredet, da es eh nur einen einzige 60Hz G-Sync-Monitor gibt ist das ganz im Gegenteil eh kaum relevant.

Dimitri Mayakovsky

2015-04-12, 16:25:21

Langsam wird es ermüdend. Willst Du es nicht verstehen?
Tut mir leid, mit krudem Bullshit habe ich tatsächlich meine Verständnisschwierigkeiten. Ich halte mich lieber an die Fakten, statt mir irgendwelche "Bugs" und Wundertreiber auszudenken und ganz, ganz feste dran zu glauben.

Du liegst falsch. Lies die alten Post! Flipflopping kannst Du mir sicherlich nicht vorwerfen. Du verstehst nur nicht, wo die Bottlenecks liegen und hast die an anderen Stellen verortet, auf die ich dann eingegangen bin. Wenn Dir das nicht aufgegangen ist, bezweifle ich langsam, daß das hier was bringt.
Selbstverständlich kann ich die Flipflopping vorwerfen und liege damit sogar noch 100% richtig, wenn du die Zusammenhänge urplötzlich wechselst, wie es dir gerade in den Kram passt. Und dies ja nicht nur in diesem Teilgebiet.

Ähm, nein. Ich habe für Dich sogar extra den Teil mit den übersprungenen Frames gefettet. Soll ich den englischen Text für Dich übersetzen? Mache ich gerne, wenn es dem Verständnis hilft.
Ich bin gespannt, dann übersetze es doch mal so, dass da der Sinn raus kommt, wie du ihn haben möchtest. Nämlich, dass Buffer in völlig unterschiedlichen Komponenten urplötzlich zusammen gezählt werden.

Übrigens können wir hier auch gern mal die deutsche WIkipedia zitieren, vielleicht entfallen da deine Verständnisschwierigkeiten:
Die Dreifachpufferung (englisch triple buffering) beschreibt ein Konzept in der Computergrafik, bei dem der Framebuffer des Video-RAM bei Grafikkarten in drei Bereiche unterteilt wird. Ziel des Verfahrens ist es, die bei gleichzeitiger Verwendung von VSync (vertikale Synchronisation) und Doppelpufferung (double buffering) auftretenden Nachteile während des Bildaufbaus zu kompensieren.

Verstehst du nun den Unterschied zwischen G-Sync und Triple Buffering? Die englische Wikipedia sagt im Grunde auch nichts anderes, wenn auch etwas verklausuliert.

Du siehst offenbar die Implikationen nicht. Also mal ganz langsam, damit das alle verstehen.
Du willst, daß während einem Refresh (der 1/Maximalrefreshrate dauert) zwei Frames fertig werden. Daß geht nur, wenn die Frametime für den zweiten Frame kleiner ist, als die Dauer des Refreshes. Was man gemeinhin auch so ausdrückt, daß die Framerate über der Refreshrate liegt(das sind schlicht die Kehrwerte).
Und dann treten genau die Probleme bei dem von Dir aufgestelltem Szenario auf, die ich beschrieben habe.
Du solltest nochmal zu meinem Posting #2290 zurück gehen, du hast offensichtlich null verstanden, was ich geschrieben habe. Immer noch nicht, auch wenn ich es dir jetzt schon näher erläutert habe.

Das, was ich dort beschriebene habe, nämlich das überspringen eines bereits übertragenen Frames, ist das völlige Gegenteil von TripleBuffering.

Du verbrämst Deine (falsche) "Erklärung" von Triple Buffering. Ich habe einen Link angeboten (was offenbar vergebene Liebesmüh war), Du nicht.
Ja das sieht man ja :facepalm:

Du hast auch nicht ohne Grund die engl. Wikipedia zitiert, weil die dt. nämlich leider genau das aussagt, was ich die ganze Zeit sage ;D Die engl. hast du mit deiner ablenkenden Fettmarkierung sinn-entstellt, grundsätzlich aber steht da auch das gleiche drin.

Und dass man Buffer von unterschiedlichen Komponenten, die über einen Bus verbunden sind, zusammen zählt, ist schlicht gröbster Unfug. Deswegen mein Netzwerkvergleich, der dir irgendwo zu hoch war.

Du kommst dann mit sowas:
Das ist schlicht Blödsinn und ziemlich belanglos, weil es keine Eigenart von GSync ist oder sonstwas. Genau das tun GPUs schon seit es GPUs gibt. Wenn zum Beginn eines Refreshzyklus kein neues Frame da ist, wird mit dem alten refreshed. Das sind die Basics, über die man kaum reden müssen sollte. Du scheiterst offenbar daran, das Wesentliche zu erkennen.
Ich erkenne das wesentliche: FreeSync ist nicht in der Lage FrameDoubling zu betreiben, wie dies G-Sync tut. Punkt. Das ist die Ausgangslage. Du denkst dir irgendeinen "Bug" Unfug aus, ohne jeden Beleg oder Indiz dafür zu haben. Selbst AMD hat auf den Test von PcPer bisher was gesagt? Genau: Nüchts.

Aber zum Glück weißt DU besser, was AMD tun kann, als das AMD selbst tut. Und wetterst du gegen meine Aussage, die nun mal Fakt ist, wie du nur kannst und schreckst nicht mal davor grundlegende Fachbegriffe wie TripleBuffering völlig falsch darzustellen, nur um mir was reinzuwürgen.

Double Buffering mit drei verschiedenen Frames in drei verschiedenen Puffern. Glaubst Du das wirklich? :freak:
Double Buffering innerhalb der GPU, s.o.

Was ist daran völlig anders, wenn ich beide Male einen Puffer von einem Ort an einen anderen kopiere? Daß die physisch etwas weiter separiert sind, als die Speicherchips auf der Grafikkarte? Toller Unterschied! Konzeptionell ist es keiner.
Ganz einfach: Weil es unterschiedliche Sachverhalte sind. Die Kopie innerhalb des Framebuffers der GPU ist etwas VÖLLIG anders, als das SEnden über den DisplayPort.

Alleine, dass du dich mit so einer Aussage hier blamierst, spricht Bände.

:freak: Ein wenig Abstraktion kann manchmal helfen.
Du meinst Fachbegriffe falsch zu nutzen? ;D

Das Programm (z.B. ein Spiel) rendert in einen Puffer. Wenn sie fertig ist, signalisiert sie das und macht dann (nach eventuell verordneter Wartezeit, weil gerade kein Puffer frei ist) mit einem (meist anderen) Puffer weiter. Die Anwendung kümmert in diesem Zusammenhang nicht, wie das Betriebssystem, der Treiber oder die Grafikkarte oder im Zweifelsfall der Monitor das genau handhaben. Das ist völlig unerheblich, wie das konkret implementiert ist. Wichtig ist, daß am Ende bei Deinem Szenario effektiv Triple Buffering rauskommt. Das von Dir vorgeschlagene Verhalten ist nämlich genau das.
Nein, es ist nicht "genau das". Unfug. Und nein, auch dein jetzt plötzlich reingezaubertes "effektiv", macht deinen bisherigen Bullshit nicht wett.

Nein, es hat nur nichts mit dem Thema zu tun. Du weigerst Dich, die Puffer zu zählen und deren Funktionalität zu erkennen. Komm schon! 1,2,3. Das ist nicht so schwer. ;)
Ja, ich weigere mich die Buffer in der GPU mit dem Buffer im Monitor zusammen zu zählen.

WEIL DAS FALSCH IST!

Latenz der Kommunikation zum Panel? Da schickt man nur was hin und die Übertragungsdauer ist weder von GSync noch von FreeSync beeinflußbar. Man muß arbeiten, mit dem was da ist. Bei beiden müssen die Daten letztendlich irgendwie zum Panel. Das ist schlicht kein Unterschied zwischen beiden Varianten (außer daß ASync natürlich nicht nur mit FPD-Links funktioniert).
Die Latenz G-Sync Modul -> Panel ist selbstverständlich deutlich niedriger, als GPU->DisplayPort->Scaler-Panel.

Zähl mal die Menge der Komponenten, dann geht sogar dir das auf :tongue:

Der feine Unterschied zwischen das Gleiche zu nutzen, um einen bestimmten Effekt zu erzielen und das Gleiche zu sein, ist Dir sicherlich nur versehentlich entgangen. Die Unterscheidung meinerseits war nicht versehentlich. Die Umsetzung, also wie man es genau nutzt, unterscheidet sich natürlich schon etwas.
Selbstverständlich nutzt NVIDIA nicht "das Gleiche", wenn sie ein Polling über den DP-Link schicken, um den Zustand des G-Sync Moduls zu checken. Das ist so ziemlich das völlige Gegenteil zum "das Gleiche".

Weil Du mir Aussagen unterstellst, die ich nicht getätigt habe.
Alleine dass du die Implementierung von G-Sync als "unnötig" und "nicht unbedingt ein Vorteil" bezeichnest, ist mehr als nur ein Witz angesichts der faktischen Unterschiede, die jeder mit bloßen Auge unterhalb des Panels Threshold wahr nehmen kann.

Und das ist ein gewaltiger Unterschied!

Tesseract

2015-04-12, 16:29:16

Es ist nur etwas völlig Anderes, ob ich einen Buffer innerhalb des Framebuffers der GPU kopiere (bzw. den Pointer ändere), oder ob ich das Frame zunächst über einen DisplayLink schicke und dann im Monitor speichere.

es muss anders implementiert werden aber das prinzip dahinter ist vergleichbar. wenn der monitor einen frame zwischenspeichert um im extremfall frames verdoppeln zu können muss sich die graka nicht um garantien kümmern. macht das der monitor nicht selbst muss die graka halt einen weiteren buffer im vram anlegen der den mindestrefresh garantiert wie das bei vsync seit vielen jahren gemacht wird. der unterschied liegt in der zusicherung, die der monitor vom protokoll bekommt, das ist alles.

Sunrise

2015-04-12, 16:30:26

Und die Programmierbarkeit? Wenn Du zwei oder drei verschiedenen Verhaltensweisen ein wenig konfigurieren kannst, reicht das doch völlig aus. Wir reden hier ja von einer Sache, deren Ziel sehr klar ist.
Wie stellst du dir das vor, wenn du gleichzeitig Scaler im Monitor sein musst, gleichzeitig artefaktfreien Overdrive regeln willst und dann noch die A-Sync-Funktionalität hinzukommt und du für viele verschiedenen Panels und Panelarten eine Erkennung benötigst.

Du kannst diverse Dinge rein technisch vielleicht perfekt trennen (Scaler und A-Sync) aber viele Dinge spielen zusammen.

Hier werden IMHO einige Dinge ziemlich kleingeredet, vor allem eine Aussage wie "kann man machen" ist absolut lächerlich.

Ja, technisch kann man viel machen, die alles entscheidende Frage die sich aber stellt ist, ob die Voraussetzungen dafür gegeben sind und ob das Ergebnis einen extrem hohen Aufwand erfordert, der aber evtl. kaum zu kontrollieren ist und man sich dann eher dafür entscheidet, als IHV ggü. den Monitorherstellern lieber so aufzutreten, dass man eine Komplettlösung anbietet, die nicht nur den Entwicklungsaufwand der Monitorhersteller minimiert, sondern man dann ein Ergebnis hat, dass den Ansprüchen genügt und das gleichzeitig auch noch relativ unabhängig von der verbauten GPU bzw. GPU-Generation.

Hier werden Diskussionen über Kleinigkeiten geführt, aber wenn ich mir die Sache so anschaue, wäre ich persönlich ebenso den NV-Weg gegangen. Jeder, der nicht dieser Meinung ist, der sollte sich mal ein paar andere Fragen stellen als "das kann man machen". Denn in dieser Welt sind die wenigsten Dinge davon gesteuert, was man tatsächlich machen kann und was im Endeffekt auch in absehbarer Zeit und mit absehbarem Aufwand (Geld) machbar ist.

fondness

2015-04-12, 16:40:12

und du für viele verschiedenen Panels und Panelarten eine Erkennung benötigst.

Wie kommst du darauf oder was verstehst du unter "Erkennung"? Bei Vsync benötige ich auch nicht für jedes Panel eine Extrawurst.

Das Prinzip des Framedoubelings ist immer dasselbe: Wenn kein neuer Frame unterhalb der min. Refreshrate fertig ist -> alten nochmal schicken.

Tesseract

2015-04-12, 16:44:05

Wie stellst du dir das vor, wenn du gleichzeitig Scaler im Monitor sein musst, gleichzeitig artefaktfreien Overdrive regeln willst und dann noch die A-Sync-Funktionalität hinzukommt und du für viele verschiedenen Panels und Panelarten eine Erkennung benötigst.

scaling und postprocessing finden nach der ganzen sync-problematik statt und haben damit eigentlich nix zu tun. für globales postprocessing (z.B. für local dimming) und solche späße braucht man sowieso zusätzliche buffer/logik, unabhängig von der übertragung bzw. synchonisation.

dargo

2015-04-12, 16:44:06

Kauf dir einen gescheiten Monitor ohne Lag. Mit dem Frostbite-Limiter treff ich hier selbst mit 75Hz 30fps was...
Aha... warum spielst du dann den MP nicht durchgehend so? :rolleyes: Erzähl mir bitte keinen Blödsinn, die FB3 ist mit 30fps (völlig egal ob 60 oder 75Hz Bildschirmrefresh) die reinste Grütze.

aufkrawall

2015-04-12, 16:47:48

Lies richtig, ich schrieb mit 30fps in-game Limit.
Und vielleicht spiel ich ja immer so? Hab dich bestimmt schon ein paar mal gekillt.
Natürlich spielt keiner so BF4. Ich spiel aber auch noch was anderes und kann gut darauf verzichten, mir von Klugscheißern wie dir vorzuschreiben lassen, wie ich etwas zu spielen hab.

dargo

2015-04-12, 16:53:41

Lies richtig, ich schrieb mit 30fps in-game Limit.

Und was ändert das daran, dass jeder Frame schon alleine 33,33ms braucht? Das sind Welten im Input! Du willst mir ernsthaft erzählen du spielst BF4 und/oder PvZ: GW mit 30fps? Ich lache mich tot. ;D

Sunrise

2015-04-12, 17:00:40

scaling und postprocessing finden nach der ganzen sync-problematik statt und haben damit eigentlich nix zu tun. für globales postprocessing (z.B. für local dimming) und solche späße braucht man sowieso zusätzliche buffer/logik, unabhängig von der übertragung bzw. synchonisation.
Es geht mir mehr um den unteren und oberen Thresholdwert und weitere Eigenschaften, die für jedes Panel anders sind. Die brauchst du, um volle G-Sync-Funktionalität zu bekommen. Wir hatten da schon z.B. über EDID gesprochen.

Kann EDID in der aktuellen Form alle diese Informationen überhaupt liefern? Wenn ja, dann wäre das für mich geklärt.

Du kannst ein Verhalten nur programmieren, wenn du die entsprechenden Werte auch hast. Und das sollten auch keine Näherungen oder Vermutungen sein, sondern im Optimalfall Werte von jedem ausgelieferten Panel. Da dieser Aufwand aber exorbitant hoch ist, kannst du entweder ein Modul bauen, dass einen gewissen Spielraum hat und das Panel auch kennt oder du kannst Werte nehmen, die dir irgendwie mitgeteilt werden müssen. Das für Fall, wenn du diesen Teil der Funktionalität in der GPU selbst hättest, und du dann per Treiber G-Sync-Funktionalität nachbilden möchtest.

aufkrawall

2015-04-12, 17:06:28

Und was ändert das daran, dass jeder Frame schon alleine 33,33ms braucht? Das sind Welten im Input! Du willst mir ernsthaft erzählen du spielst BF4 und/oder PvZ: GW mit 30fps? Ich lache mich tot. ;D
Das sind Welten, wenn der schnarchige Monitor bzw. dessen Signalverarbeitung den Input erst bei einem der nächsten Refreshes darstellen kann.
So ein Verstreichen des Zeitfensters gibts mit direktem Input nicht, wie ihn der Qnix hier mit Bypass-PCB hat. Ca. 3ms nach Ausgabe (+Refreshzeit) dürfte der Pixel bereits eine wahrnehmbare Helligkeits- und Farbveränderung erreicht haben, und das ausnahmslos.
Jetzt nochmal für die ganz humorlosen und begriffslahmen: Natürlich spiel ich keinen MP-Shooter mit 30fps.
Warum sollte ich auch, wenn die GPU in WQHD locker das Drei- bis Vierfache schafft. Ist ja kein lahmer Hawaii.
Trotzdem wär das im SP so spielbar, mit nem Pad eh und mit A-Sync noch besser.

Gipsel

2015-04-12, 17:24:47

samm

2015-04-12, 17:31:16

Kann EDID in der aktuellen Form alle diese Informationen überhaupt liefern? Wenn ja, dann wäre das für mich geklärt.EDID muss die Informationen sogar liefern, um mit Adaptive Sync kompatibel zu sein. Zitat aus dem FreeSync-Whitepaper (die VESA Spec finde ich grad nicht): The display's EDID must properly indicate that it is a "continuous frequency display" and report the range of refresh rates that the display supports.

[edit]
Eigentlich will ich mich in diese komplett sinnlose Wand-Anrede-Diskussion ja gar nicht einmischen, und es wird mir schon beim Überfliegen schon fast übel, aber manches ist einfach so hanebüchern...Ja, ich weigere mich die Buffer in der GPU mit dem Buffer im Monitor zusammen zu zählen.

WEIL DAS FALSCH IST!Triple Buffering kann man sich grundsätzlich einfach als Algorithmus vorstellen, mit zwei Backbuffern und einem Frontbuffer. Die Backbuffer werden abwechslungsweise gefüllt, der Frontbuffer wird, sobald er ready ist, mit dem Inhalt des zu dem Zeitpunkt gerade nicht beschrieben werdenden Backbuffers gefüllt, oder es wird einfach der jeweilige Backbuffer zum Frontbuffer - so oder so: entscheidend ist der Algorithmus, nicht wo sich denn nun ein Puffer genau befindet. In Dimitry-Mayakovski-Speak: "weil z.B. ein neuer Frame auch schon geladen werden könnte, wenn jetzt aber der nächste Frame schnell genug fertig wird, dieser vorgezogen werden kann - so er in Zeiten für den nächsten Refresh fertig ist."
Und davon ab dient mir dieser Mini-Teil der Diskussion vor allem dazu, zu zeigen, wie komplett neben jeglicher Relevanz für das Thema an sich es ist, auf sowas rumzureiten.

Skysnake

2015-04-12, 17:31:33

Natürlich KANN man das machen. Das habe ich nie bezweifelt. Die Frage ist: WURDE das gemacht. In der aktuellen Generation aller Grafikkarten bezweifle ich das stark.

Und ehrlich gesagt: Ich glaube auch nicht, dass das kommen wird (eine Implementierung in der DP Controller Hardware). Aber lassen wir uns überraschen.

Umgekehrt, warum sollte man es NICHT gemacht haben? Die Sache hat man sich ja nicht erst gestern überlegt, und der Aufwand ist ja wirklich ziemlich überschaubar.

Das bezweifle ich sehr stark. Denn dann hast Du Tearing oder eine feste Framerate von 40 fps (wie VSync bei 40 Hz). Beides ist echt Scheiße. Dagegen hat noch niemand optisch den Judder-Effekt durch Kollisionen der Wiederholframes nachgewiesen, darüber reden wir nur rein theoretisch.

Ich finde es schon bemerkenswert, wie ein momentaner Vorteil gerade möglichst kleingeredet wird. Warum kann man das nicht einfach mal stehen lassen und hoffen, dass AMD das so schnell wie möglich nachliefern kann? Es ist einfach sinnvoll!
Weil wir hier vielleicht über die Technik an sich reden, und nicht Monitor X mit Monitor Y vergleichen, und uns fragen, welchen wir JETZT am Besten kaufen sollten? :rolleyes:

Tut mir leid, mit krudem Bullshit habe ich tatsächlich meine Verständnisschwierigkeiten. Ich halte mich lieber an die Fakten, statt mir irgendwelche "Bugs" und Wundertreiber auszudenken und ganz, ganz feste dran zu glauben.

Ganz ehrlich, wenn hier einer bullshit verzapft, dann du. Du kommst doch immer wieder mit leichten Abwandlungen daher, bzw. bist einfach ungenau in deinen Erklärungen, was dazu führt, das man eben mehrere Varianten durchkauen muss...

Ich bewundere Gipsel echt, wie er so ruhig bleiben kann...

Die Latenz G-Sync Modul -> Panel ist selbstverständlich deutlich niedriger, als GPU->DisplayPort->Scaler-Panel.

Zähl mal die Menge der Komponenten, dann geht sogar dir das auf :tongue:

Wie hoch sind die denn? 10ns oder doch 100ns? ODer sind es vielleicht sogar 1 µs??? Schau dir doch mal an, mit welchen Taktraten das läuft... Die Latenzen werden da nicht sonderlich hoch sein, sonst brüchte man gigantische Buffer... Vor allem aber sind die Latenzen da mal ziemlich banane im Vergleich zu den Latenzen, die du einfach durch die Displayansteuerung hast.

Wie stellst du dir das vor, wenn du gleichzeitig Scaler im Monitor sein musst, gleichzeitig artefaktfreien Overdrive regeln willst und dann noch die A-Sync-Funktionalität hinzukommt und du für viele verschiedenen Panels und Panelarten eine Erkennung benötigst.

Du kannst diverse Dinge rein technisch vielleicht perfekt trennen (Scaler und A-Sync) aber viele Dinge spielen zusammen.

Hier werden IMHO einige Dinge ziemlich kleingeredet, vor allem eine Aussage wie "kann man machen" ist absolut lächerlich.

Wo besteht denn der Unterschied zu nem FPGA? Der muss auch alles auf einmal können.

Wichtig ist doch an sich erstmal nur, das man die Grundlegenden Protokolle unterstützt, und die elektrischen Signale die richtigen Parameter haben.

Was man dann nochmals an sonstigen Postprocessing usw macht, ist man ziemlich wurst. Ob ich jetzt nen Overdrive von 1.0 oder 1.1 habe, ist völlig egal! Ich muss halt nur ein Register beschreiben, welches die entsprechende Auflösung der Werte ermöglicht. Das ist, wenn man es direkt bedenkt überhaupt kein Aufwand. Der größte Aufwand ist es da noch, die REgister von außen beschreibbar zu machen, aber das Problem löst man genau einmal, und macht dann nur noch copy&paste....

Ja, technisch kann man viel machen, die alles entscheidende Frage die sich aber stellt ist, ob die Voraussetzungen dafür gegeben sind und ob das Ergebnis einen extrem hohen Aufwand erfordert, der aber evtl. kaum zu kontrollieren ist und man sich dann eher dafür entscheidet, als IHV ggü. den Monitorherstellern lieber so aufzutreten, dass man eine Komplettlösung anbietet, die nicht nur den Entwicklungsaufwand der Monitorhersteller minimiert, sondern man dann ein Ergebnis hat, dass den Ansprüchen genügt und das gleichzeitig auch noch relativ unabhängig von der verbauten GPU bzw. GPU-Generation.

Hier werden Diskussionen über Kleinigkeiten geführt, aber wenn ich mir die Sache so anschaue, wäre ich persönlich ebenso den NV-Weg gegangen. Jeder, der nicht dieser Meinung ist, der sollte sich mal ein paar andere Fragen stellen als "das kann man machen". Denn in dieser Welt sind die wenigsten Dinge davon gesteuert, was man tatsächlich machen kann und was im Endeffekt auch in absehbarer Zeit und mit absehbarem Aufwand (Geld) machbar ist.
Komm schon, jedweder halbwegs denkende Scaler Entwickler wird die ganzen für Panels relevanten Parameter eben über Register konfigurierbar machen. So blöd, die Werte fix in Hardware zu bauen ist doch hoffentlich niemand. Die Technik ist viel zu schnelllebig und vielfältig, als das man das machen wollen würde, zumal der Aufwand eben sehr klein ist.

Es geht mir mehr um den unteren und oberen Thresholdwert und weitere Eigenschaften, die für jedes Panel anders sind. Die brauchst du, um volle G-Sync-Funktionalität zu bekommen. Wir hatten da schon z.B. über EDID gesprochen.

Kann EDID in der aktuellen Form alle diese Informationen überhaupt liefern? Wenn ja, dann wäre das für mich geklärt.

Du kannst ein Verhalten nur programmieren, wenn du die entsprechenden Werte auch hast. Und das sollten auch keine Näherungen oder Vermutungen sein, sondern im Optimalfall Werte von jedem ausgelieferten Panel. Da dieser Aufwand aber exorbitant hoch ist, kannst du entweder ein Modul bauen, dass einen gewissen Spielraum hat und das Panel auch kennt oder du kannst Werte nehmen, die dir irgendwie mitgeteilt werden müssen. Das für Fall, wenn du diesen Teil der Funktionalität in der GPU selbst hättest, und du dann per Treiber G-Sync-Funktionalität nachbilden möchtest.
DP ist bidirektional, also kannste jedwede Information übertragen. Sender und Empfänger müssen sich nur verstehen. Da man eh neue Scaler dafür brauchen wird, ist es kein Ding, das zu implementieren. Die Werte müssen! ja bekannt sein. Also kannste Sie auch der GPU senden. Das ist überhaupt kein Thema.

Das sind Welten, wenn der schnarchige Monitor bzw. dessen Signalverarbeitung den Input erst bei einem der nächsten Refreshes darstellen kann.
So ein Verstreichen des Zeitfensters gibts mit direktem Input nicht, wie ihn der Qnix hier mit Bypass-PCB hat. Ca. 3ms nach Ausgabe (+Refreshzeit) dürfte der Pixel bereits eine wahrnehmbare Helligkeits- und Farbveränderung erreicht haben, und das ausnahmslos.
Jetzt nochmal für die ganz humorlosen und begriffslahmen: Natürlich spiel ich keinen MP-Shooter mit 30fps.
Warum sollte ich auch, wenn die GPU in WQHD locker das Drei- bis Vierfache schafft. Ist ja kein lahmer Hawaii.
Trotzdem wär das im SP so spielbar, mit nem Pad eh und mit A-Sync noch besser.
Jetzt mal ganz ernst gefragt, warum lässt du dann so einen Stuss ab? Ging e mal wieder nur ums reine Bashing/Trolling?

Gipsel

2015-04-12, 17:32:00

Es geht mir mehr um den unteren und oberen Thresholdwert und weitere Eigenschaften, die für jedes Panel anders sind. Die brauchst du, um volle G-Sync-Funktionalität zu bekommen. Wir hatten da schon z.B. über EDID gesprochen.
Kann EDID in der aktuellen Form alle diese Informationen überhaupt liefern? Wenn ja, dann wäre das für mich geklärt.Die weiteren Eigenschaften (wie z.B. Overdrive und so) gehören wie Tesseract wohl meinte in die Panelelektronik. Das Sync-Geraffel muß davon nichts wissen. Das benötigt die minimale und maximale Refreshrate des Panels. Mehr nicht. Und das geht über EDID. Die ASync-Erweiterung der VESA DP-Spec definiert die nötigen Einträge dafür. Auch für Sachen wie das Framedoubling brauchst Du nicht mehr.

Unicous

2015-04-12, 17:36:30

@Sunrise

Es gibt seit Ewigkeiten von VESA einen neuen Standard den (so gut wie) keine Sau zu nutzen scheint: Display ID. AMD hatte 2013 sogar eine Revision eingereicht um z.B. Tiling und 4K zu ermöglichen. Die einzigen Monitore die DisplayID (v 1.3) nutzen dürften eben diese sein, z.B. der UltraSharp UP2414Q (und Apple?) unterstützt.

EDID ist dafür wahrscheinlich zu beschränkt.

Außerdem gibt es ja auch noch VDIF (VESA Display Identification File) über den Display Data Channel (DDC) der die Kommunikation zwischen GPU und Panel ermöglicht.

Es dürfte also eigentlich kein Problem sein. Nur haben die Panel- und Monitorhersteller da einfach keine Lust etwas einzuführen das kurzfristig keine Vorteile bietet. Dadurch stagniert aber auch die Entwicklung und wir leiden darunter. Jetzt mit 4K werden sie dazu gezwungen es zu nutzen, weil auch das HDMI Konsortium geschlafen hat.

aufkrawall

2015-04-12, 17:52:02

Jetzt mal ganz ernst gefragt, warum lässt du dann so einen Stuss ab? Ging e mal wieder nur ums reine Bashing/Trolling?
Ich bashe nicht und trolle nur ein bisschen.
Die fps-Polizei hier, bestehend aus dargo und co, stellt aber gerne mal als allgemeingültig dar, dass kein A-Sync Limit nach unten quasi unnötig wäre.
Ist aber Schwachsinn^10, es muss nur mal irgendein in-game Video mit 30fps starten und schon gibts wieder Tearing aus der Hölle...
Solche Fehler passieren, wenn der eigene Horizont nur bis zum Tellerrand reicht.

Sunrise

2015-04-12, 17:58:41

@samm, Skysnake, Gipsel, Unicous:
Danke.

Ok, somit ist für mich dann auch ziemlich sonnenklar, dass man im Prinzip die Displayengine nur noch so flexibel auslegen muss, dass diese sich nicht nur an die Specs hält, sondern auch Sonderfunktionalität enthält, bzw. dies auch teilweise vom Treiber gesteuert wird. Ich sehe da eigentlich keinen Grund mehr, warum man G-Sync nicht nachbilden kann, wenn man auch lokal per GPU ja sowieso alle Bilder direkt zur Verfügung hat und diese nur in der angedachten Form per DP zum Monitor schicken muss.

Allerdings kann das G-Sync-Modul auch Dinge wie ULMB, die zwar nicht gleichzeitig aber zusätzlich möglich sind. Sowas müsste dann aber wieder vom Monitorhersteller kommen. Wobei mir eh nicht klar ist, wer das überhaupt nutzt.

Troyan

2015-04-12, 18:00:16

Und was ändert das daran, dass jeder Frame schon alleine 33,33ms braucht? Das sind Welten im Input! Du willst mir ernsthaft erzählen du spielst BF4 und/oder PvZ: GW mit 30fps? Ich lache mich tot. ;D

Vielleicht spielt er ja AC:Unity. Dort erreicht selbst eine übertaktete GTX980 mit FXAA in 1440p gerademal Frames zwischen 40-60FPS. Die Ingame-Cutszenen laufen mit <40FPS wegen der besseren Qualität.

Und die GTX980 ist in diesem Spiel durchschnittlich 30% besser als eine 290X.

Dimitri Mayakovsky

2015-04-12, 18:01:33

Triple Buffering kann man sich grundsätzlich einfach als Algorithmus vorstellen, mit zwei Backbuffern und einem Frontbuffer.
Ja, in EINER (!) Komponente (in unserem Falle der GPU).

Nicht, so wie Gipsel, in GPU + Monitor. Das ist völliger Quatsch, sogar auf Wissen nach Wikipedia-Niveau.

Umgekehrt, warum sollte man es NICHT gemacht haben? Die Sache hat man sich ja nicht erst gestern überlegt, und der Aufwand ist ja wirklich ziemlich überschaubar.
Dass FreeSync ein Schnellschuß von AMD gegen G-Sync ist, wissen wir doch inzwischen.

Ganz ehrlich, wenn hier einer bullshit verzapft, dann du. Du kommst doch immer wieder mit leichten Abwandlungen daher, bzw. bist einfach ungenau in deinen Erklärungen, was dazu führt, das man eben mehrere Varianten durchkauen muss...

Ich bewundere Gipsel echt, wie er so ruhig bleiben kann...
Das Abschalten von FreeSync unterhalb der Panel-Refreshrate ist ein Fakt und kein Bullshit. Spar dir deinen Müll, nur um dich bei Gipsel einzuschleimen. Von dem kam bisher außer völlig falsch wiedergegebener Fachbegriffe und Behauptungen ohne jedes Substanz exakt gar nix.

Wie hoch sind die denn? 10ns oder doch 100ns? ODer sind es vielleicht sogar 1 µs??? Schau dir doch mal an, mit welchen Taktraten das läuft... Die Latenzen werden da nicht sonderlich hoch sein, sonst brüchte man gigantische Buffer... Vor allem aber sind die Latenzen da mal ziemlich banane im Vergleich zu den Latenzen, die du einfach durch die Displayansteuerung hast.
Die Latenz von DisplayPort liegt im Milisekundenbereicht, LVDS um einiges darunter.

DP ist bidirektional, also kannste jedwede Information übertragen. Sender und Empfänger müssen sich nur verstehen. Da man eh neue Scaler dafür brauchen wird, ist es kein Ding, das zu implementieren. Die Werte müssen! ja bekannt sein. Also kannste Sie auch der GPU senden. Das ist überhaupt kein Thema.
Quatsch, wenn du das DP-"Protokoll" dass du einsetzt modifizierst, hast du natürlich ein propreitäres Protokoll. So wie eben bei G-Sync. Es mag (große) Teile von DisplayPort übernehmen, aber weder spricht eine DP-GPU automatisch G-Sync, noch ein DP-Monitor. Das klappt nur, wenn beide Komponent propreitäre Erweiterungen verstehen. Und damit ist es kein DP mehr.

Jetzt mal ganz ernst gefragt, warum lässt du dann so einen Stuss ab? Ging e mal wieder nur ums reine Bashing/Trolling?
Es ist durchaus fraglich, warum ein massiver Vorteil von G-Sync hier von vereinten Kräften aus der üblichen Ecke klein- bzw. weggeredet werden will. Schau dir die Videos mit FreeSync unterhalb des Threshold an, das ist grauenvoll. Und dafür einen Aufpreis zahlen?

Wenn ich sowieso aufpassen muss, dass meine Settings bei 40Hz+ sind, dann kann ich auch direkt meinen Monitor mit 60 Hz VSync betreiben und die ein oder zwei Settings für 60 stabil auch runterschrauben. DAS ist der Aufpreis für FreeSync schlicht nicht wert.

dargo

2015-04-12, 18:02:15

Ich finde es schon bemerkenswert, wie ein momentaner Vorteil gerade möglichst kleingeredet wird. Warum kann man das nicht einfach mal stehen lassen und hoffen, dass AMD das so schnell wie möglich nachliefern kann? Es ist einfach sinnvoll!
Tjo... ich finde es auch bemerkenswert wie man einen Vorteil hervorhebt den es für einige Spieler gar nicht gibt. Wie ich schon zig mal sagte... nicht jeder will mit so wenig fps rumkriechen. Ist aber das selbe wie mit dem DSR von NV. Einige habens gefeiert, ich fands nur gääähn. Ganz einfach weil ich es nicht nutze.

Troyan

2015-04-12, 18:06:11

Oh, ich wollte eigentlich nicht ein zweites Posting schrieben, aber:
Dying Light: http://www.hardware.fr/articles/933-15/benchmark-dying-light.html

42FPS in 1440p - als Durchschnitt.

Oder Lords of the Fallen: http://pclab.pl/art62452-17.html
38 FPS mit einer übertaktete 290X.

Und die Anforderungen werden in Zukunft weiter steigen.

Dimitri Mayakovsky

2015-04-12, 18:06:58

Tjo... ich finde es auch bemerkenswert wie man einen Vorteil hervorhebt den es für einige Spieler gar nicht gibt. Wie ich schon zig mal sagte... nicht jeder will mit so wenig fps rumkriechen.
Wenn du sowieso 120fps+ haben willst, bist du einfach nicht die Zielgruppe einer variablen Refreshrate.

Dann aber solltest du auch nicht bewerten, welcher Vor- oder Nachteil nun relevant wäre.

Sunrise

2015-04-12, 18:22:20

Tjo... ich finde es auch bemerkenswert wie man einen Vorteil hervorhebt den es für einige Spieler gar nicht gibt. Wie ich schon zig mal sagte... nicht jeder will mit so wenig fps rumkriechen. Ist aber das selbe wie mit dem DSR von NV. Einige habens gefeiert, ich fands nur gääähn. Ganz einfach weil ich es nicht nutze.
Es geht mir und sicher auch einigen anderen persönlich bei dem minimalen Threshold mehr um einen Sicherheitsspielraum als um die Art, wie man ein Spiel dauerhaft spielen möchte. Der typische PC-Spieler will zwar auch Optik, aber ich will definitv keine Ruckelorgie. Da du aber niedrigere FPS mit A-Sync noch gut fahren kannst, entschärft das etwas das generelle Problem. Deine Ausführungen lesen sich so, als ob du noch kein G-Sync getestet hast.

Wenn du natürlich deine Spiele so spielst und konfigurierst, dass du immer deutlich über 60fps sein solltest, dann hast du in der Tat Recht, dieser Vorteil ist keiner mehr. Allerdings sollte dann auch eine Range von min. 40-120Hz gegeben sein.

Gipsel

2015-04-12, 18:32:08

@Dimitri:
Ich nehme bedauernd zur Kenntnis, daß Du mein Bitte um eine kompakte Antwort mit der Formulierung Deines Problems ignoriert hast.
Aber ich spar mir mal, auf einige Dinge einzugehen und bleibe etwas sachlicher.
Selbstverständlich kann ich die Flipflopping vorwerfen und liege damit sogar noch 100% richtig, wenn du die Zusammenhänge urplötzlich wechselst, wie es dir gerade in den Kram passt.Wo genau? Ich habe lediglich auf Dein Verkennen von Zusammenhängen reagiert und auf diese hingewiesen.
Ich bin gespannt, dann übersetze es doch mal so, dass da der Sinn raus kommt, wie du ihn haben möchtest. Nämlich, dass Buffer in völlig unterschiedlichen Komponenten urplötzlich zusammen gezählt werden.Wer wechselt jetzt was? Deine Aussage war, daß Triple Buffering keine Frames überspringen kann. Daß das so nicht stimmt, zeigt exakt die gefettete Stelle aus meinem Text. Wo sich die Puffer befinden, ist für das Konzept irrelevant, wie Tesseract ebenfalls schon anmerkte.
Übrigens können wir hier auch gern mal die deutsche WIkipedia zitieren, vielleicht entfallen da deine Verständnisschwierigkeiten:

Verstehst du nun den Unterschied zwischen G-Sync und Triple Buffering? Die englische Wikipedia sagt im Grunde auch nichts anderes, wenn auch etwas verklausuliert.Auch die deutsche Wikipedia enthält das Überspringen von Frames, wenn auch nicht explizit so formuliert. Aber durchdenke mal den angegebenen Algorithmus ;)
Durch einen weiteren Backbuffer kann die Bildrate des Monitors von der GPU entkoppelt werden. Wenn ein Bild fertiggestellt ist, muss die GPU nun nicht mehr warten, bis der Swap-Befehl ausgeführt wird, sondern kann direkt im anderen Backbuffer weiterarbeiten. Beim Auftreten des Swap-Befehls werden also die beiden Backbuffer vertauscht, während beim Auftreten von VSync der Frontbuffer und der (letzte) fertig berechnete Backbuffer vertauscht werden.
Du solltest nochmal zu meinem Posting #2290 zurück gehen, du hast offensichtlich null verstanden, was ich geschrieben habe. Immer noch nicht, auch wenn ich es dir jetzt schon näher erläutert habe.

Das, was ich dort beschriebene habe, nämlich das überspringen eines bereits übertragenen Frames, ist das völlige Gegenteil von TripleBuffering.:freak:
Was ist anders, als wenn ich mit Hilfe von Triple Buffering ein Frame überspringe?
Mal ganz abgesehen davon, daß Du (wie schon mehrfach erwähnt und von Dir ignoriert) schnell in Probleme läufst, wenn Du ein Frame in weniger als der Dauer eines Refreshes (1/maximale Refreshrate) übertragen willst, was dafür nämlich notwendig wäre. Oder die GPU und GSync müßten es beherrschen, den laufenden Transfer eines Frames abzubrechen. Die GPU-seitige Lösung hat diese Probleme prinzipiell nicht.
Ich erkenne das wesentliche: FreeSync ist nicht in der Lage FrameDoubling zu betreiben, wie dies G-Sync tut. Punkt. Das ist die Ausgangslage. Du denkst dir irgendeinen "Bug" Unfug aus, ohne jeden Beleg oder Indiz dafür zu haben. Selbst AMD hat auf den Test von PcPer bisher was gesagt? Genau: Nüchts.Daß es nicht um die "Ausgangslage" geht, sondern darum, was man ohne GSync-Modul im Monitor tun kann, ist an Dir vorbei gegangen? Der momentane Stand individueller Implementationen ändert nichts an prinzipiellen Sachen.
Double Buffering innerhalb der GPU, s.o.Was in Deinem Szenario für die Anwendung transparent zu TripleBuffering aufgebohrt wird. Und bevor Du sagst, daß ginge nicht (das transparent für die Anwendung), OpenGL beweist das Gegenteil. Bei Deinem Szenario liegt der dritte Puffer mit dem dritten Frame nur auf dem GSync-Modul. So what?
Ganz einfach: Weil es unterschiedliche Sachverhalte sind. Die Kopie innerhalb des Framebuffers der GPU ist etwas VÖLLIG anders, als das SEnden über den DisplayPort.Es ist vorher ein Frame im Speicher und es nachher ein Frame im Speicher (des GSync-Moduls). Es wird zwischen den Speichern kopiert, was auch im VRAM der GPU eine Möglichkeit ist (nicht immer wird geflippt). Wie soll es da etwas völlig Anderes sein?
Es stellt in Deinem Szenario den Frontbuffer dar (das Frame zur Anzeige), aus dem das Display seine Bilddaten erhält, während die GPU zwei Backbuffer hält (keines davon wird in dem Moment zur Anzeige benutzt). Das ist per Definition TripleBuffering.
Die Replik mit einem Netzwerkvergleich (der Raubkopien und Vervielfältigungen beinhalten würde) spare ich mir mal. ;)
Ja, ich weigere mich die Buffer in der GPU mit dem Buffer im Monitor zusammen zu zählen.Du weigerst Dich also. Argumente brauchst Du nicht. Und Pi ist exakt drei. Dann wäre das also geklärt.
Die Latenz G-Sync Modul -> Panel ist selbstverständlich deutlich niedriger, als GPU->DisplayPort->Scaler-Panel.Was wie erläutert unerheblich ist. Es spielt schlicht keine Rolle. Das GSync-Modul hat die Information über einen neuen Frame exakt so viel später, wie die Übertragung von der GPU dahin benötigt. Wie soll es denn da einen Timing-Vorteil bei Entscheidungen über ein anzuzeigendes Frame haben? Den gibt es nicht.
Nenne mir doch mal ein Szenario, was davon profitieren könnte!
Zumal wie Skysnake schon anmerkte, wir hier von Zeitskalen im µs bis sub-µs-Bereich reden.

Grestorn

2015-04-12, 18:34:25

Umgekehrt, warum sollte man es NICHT gemacht haben? Die Sache hat man sich ja nicht erst gestern überlegt, und der Aufwand ist ja wirklich ziemlich überschaubar.

Weil es dann sicher auch funktionieren würde, wenn man sich schon die Mühe gemacht hätte, das in HW zu gießen.

Unicous

2015-04-12, 18:38:08

dargo

2015-04-12, 18:44:43

Vielleicht spielt er ja AC:Unity. Dort erreicht selbst eine übertaktete GTX980 mit FXAA in 1440p gerademal Frames zwischen 40-60FPS. Die Ingame-Cutszenen laufen mit <40FPS wegen der besseren Qualität.

AC: U ist ein Fall für sich. Dank nicht abschaltbaren Mouse-Smoothness ist die Steuerung extrem laggy. Als ich noch die GTX970 hatte habe ich das eine und andere Detail für Full-HD reduziert damit ich öfter mal in den Bereich von 60-80fps komme. Damit empfand ich es einigermaßen brauchbar, perfekt war die Steuerung noch lange nicht. Dafür bräuchte es schon 100+fps. Ist übrigens der Hauptgrund warum ich das Game nicht mehr weiter gespielt habe. Absolut katastrophale Input Reaktion.

Oh, ich wollte eigentlich nicht ein zweites Posting schrieben, aber:
Dying Light: http://www.hardware.fr/articles/933-15/benchmark-dying-light.html

42FPS in 1440p - als Durchschnitt.

Oder Lords of the Fallen: http://pclab.pl/art62452-17.html
38 FPS mit einer übertaktete 290X.

Und die Anforderungen werden in Zukunft weiter steigen.
Irrelevant da mich max. Details nicht interessieren wenn die fps zu niedrig für mich sind. Zumal wir immer näher an einen Punkt kommen wo manche Detailstufen optisch wenig bringen aber überproportional viel kosten. Ich habe kein Problem mit meinem Ego das eine oder andere Detail eine Stufe tiefer zu wählen, auch nicht mit der gerade erworbenen Grafikkarte.

Wenn du sowieso 120fps+ haben willst, bist du einfach nicht die Zielgruppe einer variablen Refreshrate.

Wo hast du das jetzt her? Ich habe nirgendwo deartiges gesagt. Aber falls du schon fragst... im SP liegt die Grenze bei ca. 45-48 min.fps. Im MP natürlich einiges höher. Und warum sollte man sich selbst mit 120fps nicht für eine variable Refreshrate interessieren? Selbst wenn es die Hardware geben würde die mir in jedem Spiel mindestens 120fps liefert habe ich Nachteile. Mit einem 120fps Framelimit Tearing, mit Vsync On zusätzlicher Input-Lag. Klar... mit immer höherer Refreshrate und fps hat sich der negativ wahrgenommene Input-Lag selbst mit Vsync On irgendwann erledigt. Aber gewiss noch nicht bei 120fps.

Gipsel

2015-04-12, 18:47:10

Allerdings kann das G-Sync-Modul auch Dinge wie ULMB, die zwar nicht gleichzeitig aber zusätzlich möglich sind. Sowas müsste dann aber wieder vom Monitorhersteller kommen.Das kann nicht das GSync-Modul per se, sondern das Backlight des Panels und dessen Ansteuerung ;). Gibt ja etliche Monitore ohne GSync, die das können.

Gipsel

2015-04-12, 18:48:22

Weil es dann sicher auch funktionieren würde, wenn man sich schon die Mühe gemacht hätte, das in HW zu gießen.Konfigurierbare Hardware kann man unterschiedlich (oder auch falsch) konfigurieren ;).
Oder es man hat einen Bug eingebaut.

aufkrawall

2015-04-12, 18:48:50

AC: U ist ein Fall für sich. Dank nicht abschaltbaren Mouse-Smoothness ist die Steuerung extrem laggy. Als ich noch die GTX970 hatte habe ich das eine und andere Detail für Full-HD reduziert damit ich öfter mal in den Bereich von 60-80fps komme. Damit empfand ich es einigermaßen brauchbar, perfekt war die Steuerung noch lange nicht. Dafür bräuchte es schon 100+fps. Ist übrigens der Hauptgrund warum ich das Game nicht mehr weiter gespielt habe. Absolut katastrophale Input Reaktion.
Mensch, so wie du dich anstellst, ist es überhaupt ein Wunder, dass du noch irgendwas mit 60Hz spielen kannst...

Kriton

2015-04-12, 18:51:03

Die Latenz G-Sync Modul -> Panel ist selbstverständlich deutlich niedriger, als GPU->DisplayPort->Scaler-Panel.

Zähl mal die Menge der Komponenten, dann geht sogar dir das auf :tongue:

Auch wenn die Aussage hinsichtlich der Latenz (so gering der Unterschied auch sein mag) im Ergebnis wohl richtig sein dürfte (wie Unicous schon fragte: Wo ist der Beweis? - den ein gewisser jemand ja sonst immer selbst einfordert): Dieses "Argument" ist schon witzig - Latenzen der beteiligten Komponenten sind natürlich alle gleich, so dass garantiert allein die Anzahl der involvierten Komponenten relevant ist... :rolleyes: (und noch einmal: Ich vermute er hat recht, aber auf diese Weise zu "argumentieren").

Hinsichtlich des tripple buffering wäre es vermutlich hilfreich, wenn man sich von der semantischen Diskussion lösen würde und die Frage stellen würde ob es mit Blick auf die Ausgangsfrage eine Relevanz hat.

@ Gipsel:
Ich weiß nicht ob ich Dich bemitleiden oder bedauern soll.

Ansonsten: :popcorn:

Sunrise

2015-04-12, 18:51:39

Das kann nicht das GSync-Modul per se, sondern das Backlight des Panels und dessen Ansteuerung ;). Gibt ja etliche Monitore ohne GSync, die das können.
Du meinst also das geht komplett am G-Sync-Modul vorbei? Die Frage ist, wo genau die Grenze ist, da das G-Sync-Modul auch die Scalereinheit ist. Irgendwer muss ULMB ja steuern, zumindest ist das meinem Verständnis nach also dennoch das G-Sync-Modul.

Gipsel

2015-04-12, 18:55:42

Ähm kann mich mal jemand aufklären warum LVDS eine geringere Latenz aufweisen soll als DP, wie von Dimitri Mayakovsky behauptet (natürlich ohne Beweis).

Ich habe dazu leider nichts gefunden auf die Schnelle, es ist für mich aber nicht nachvollziehbar.Bei unidirektionalen Links wie für die Bilddaten ist die Definition einer Latenz von vornherein problematisch oder nicht zielführend. Irrelevant ist es hier noch dazu. Aber nun ja. :rolleyes:

Gipsel

2015-04-12, 19:01:56

Das Backlight führt die Kommandos ja nur aus, die genaue Ansteuerung und die Befehle kommen aus dem G-Sync-Modul. Daher meinte ich ja, dass das dann ohne G-Sync-Modul wieder vom Monitorhersteller kommen müsste, da das G-Sync-Modul eben als "Steuereinheit" agiert und der Monitorhersteller nur noch das Panel zusammenbauen muss. Ohne das G-Sync-Modul ist der Monitor quasi tot.Das Backlight und deren Regelung kommt doch sowieso vom Monitorhersteller. Ob man das dem GSync-Modul überläßt, das zu konfigurieren oder ob das wie bei jedem anderen Monitor der Hersteller selber macht, sehe ich da nicht als Hindernis. Baut nicht ein Hersteller bei einem Modell sogar alles doppelt ein, so daß man nur im GSync-Modus auf das Modul zurückgreifen muß und man auch eigene Funktionen anbieten kann?
NVidia soll gute GPUs bauen und Monitorhersteller gute Monitore.

dargo

2015-04-12, 19:07:56

Mensch, so wie du dich anstellst, ist es überhaupt ein Wunder, dass du noch irgendwas mit 60Hz spielen kannst...
Ich weiß nicht ob es dir noch nicht aufgefallen ist. Aber im Moment habe ich mindestens 6 Monate Pause (für mich brauchbare Freesync Bildschirme brauchen noch Zeit) was Daddeln angeht weil mich eben die Nachteile ohne variable Refreshrate nur noch ankotzen. Eigentlich kotzt mich das ineffiziente DX11 auch an, ist halt ein anderes Thema. Von daher passt das mit der Pause auch ganz gut.

Unicous

2015-04-12, 19:08:34

@Gipsel

Ja, beim XL2420G gibt es einen normalen "Scaler" und das G-Sync Modul, beim sogenannten "Classic Mode" kann man momentan aber nur auf die HDMI und DVI Ports als Eingänge umschalten und hat dann Features die man bei G-Sync nicht abbilden kann.

http://gaming.benq.com/HTML/en/gaming-monitor/xl2420g/img/features/gsync.png

Also war das mit der Latenz nur ein Strohmann-Argument. Naja, war ja nicht anders zu erwarten. ;)

Sunrise

2015-04-12, 19:09:23

Das Backlight und deren Regelung kommt doch sowieso vom Monitorhersteller. Ob man das dem GSync-Modul überläßt, das zu konfigurieren oder ob das wie bei jedem anderen Monitor der Hersteller selber macht, sehe ich da nicht als Hindernis. Baut nicht ein Hersteller bei einem Modell sogar alles doppelt ein, so daß man nur im GSync-Modus auf das Modul zurückgreifen muß und man auch eigene Funktionen anbieten kann?
NVidia soll gute GPUs bauen und Monitorhersteller gute Monitore.
Ja, es könnte ein Bypass sein, das wird eben bisher nicht sonderlich klar, weil ja immer von Scaler geredet wird, der normalerweise aber auch die Steuerlogik (auch für ULMB) enthalten sollte. Evtl. ist dieser Teil dann in der Tat doppelt.

Andererseits gibt NV ja auch ULMB als Feature vom G-Sync-Modul an, wenn ich das richtig im Kopf habe. Das würde dem dann wieder widersprechen.

Raspo

2015-04-12, 19:10:58

Ja, in EINER (!) Komponente (in unserem Falle der GPU).

Nicht, so wie Gipsel, in GPU + Monitor. Das ist völliger Quatsch, sogar auf Wissen nach Wikipedia-Niveau.
--> Weil?

Dass FreeSync ein Schnellschuß von AMD gegen G-Sync ist, wissen wir doch inzwischen.
--> Weil?

Das Abschalten von FreeSync unterhalb der Panel-Refreshrate ist ein Fakt und kein Bullshit. Spar dir deinen Müll, nur um dich bei Gipsel einzuschleimen. Von dem kam bisher außer völlig falsch wiedergegebener Fachbegriffe und Behauptungen ohne jedes Substanz exakt gar nix.
--> Weil?

Ich finde es an sich gut, wie andere auch, dass Du Dir mit Gipsel die Argumente umd die Ohren haust.
Aber mir gefällt Dein (teilweise) unsachlicher Stil überhaupt nicht. Und Du negierst größtenteils Aussagen wie oben, ohne diese zu begründen bzw. zu wiederlegen. Kannst Du oder willst Du nicht?

Entweder Ihr sprecht aneinander vorbei, was ja absolut legitim ist, oder es ist gewollt, damit man immer dagegen sein kann und den anderen klein macht.
Gipsel hat Dir völlig sachlich angeboten in Kurzform darzulegen, was Deinen Knackpunkte zwischen G-Sync und Freesync sind. Dieser bist Du nicht nachgekommen, und bist auch gar nicht drauf eingegangen.

Sieht für mich, vorsichtig ausgedrückt, "unvorteilhaft" für Dich aus. Sehr schade.

Dimitri Mayakovsky

2015-04-12, 19:38:21

@Dimitri:
Ich nehme bedauernd zur Kenntnis, daß Du mein Bitte um eine kompakte Antwort mit der Formulierung Deines Problems ignoriert hast.
Gratulation, Gipsel. Ich hoffe jetzt sperrst du dich wenigstens selbst mit 5 Punkten für exzessives Trolling.

Du hast doch selbst auf meinen Post GEANTWORTET, der diese Diskussion ausgelöst hat:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=10584579&postcount=2259

Und da muss man sich hier von den üblichen Spaten als Troll geschimpfen lassen (natürlich ohne Mod-Sanktionen), während du hier die ganze herum trollst und nicht mal weißt, worum es geht :facepalm:

Aber ich spar mir mal, auf einige Dinge einzugehen und bleibe etwas sachlicher.
Sachlich wäre von dir mal was Neues...

Wo genau? Ich habe lediglich auf Dein Verkennen von Zusammenhängen reagiert und auf diese hingewiesen.
Das hatte ich hier bereits geschrieben:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=10584799&postcount=2284

Wer wechselt jetzt was? Deine Aussage war, daß Triple Buffering keine Frames überspringen kann. Daß das so nicht stimmt, zeigt exakt die gefettete Stelle aus meinem Text. Wo sich die Puffer befinden, ist für das Konzept irrelevant, wie Tesseract ebenfalls schon anmerkte.
Nein, Triple Buffering kann auch keine schon zum Monitor übertragenen Frames überspringen :facepalm:

TripleBuffering kann maximal IN DER GPU Frames überspringen. Das ist aber etwas völlig Anderes als das, was ich geschrieben habe.

Auch die deutsche Wikipedia enthält das Überspringen von Frames, wenn auch nicht explizit so formuliert. Aber durchdenke mal den angegebenen Algorithmus ;)
Ich muss gar nichts durchdenken, weil 2+1 Buffer schlicht kein TripleBuffering ist, wie Wikipedia dir ja selbst sagt.

WP-Argumente sind lame
Ach, jetzt auf einmal, wenn sie deinen Bullshit widerlegen? ;D

Beim Auftreten des Swap-Befehls werden also die beiden Backbuffer vertauscht, während beim Auftreten von VSync der Frontbuffer und der (letzte) fertig berechnete Backbuffer vertauscht werden.[/spoiler]
So und wo kann G-Sync jetzt im Falle eines Swap-Befehl seine Back-Buffer vertauschen? Ach stimmt, hat ja gar keine zwei Back-Buffer. Blöd. Vielleicht Front- und Back-Buffer? Ne, G-Sync hat ja nur einen Buffer. Noch blöder.

Macht wie zu erwarten keinen Sinn.

[QUOTE=Gipsel;10587179]Was ist anders, als wenn ich mit Hilfe von Triple Buffering ein Frame überspringe?
Weil Triple Buffering innerhalb der GPU passiert, G-Sync ja aber eben nicht.

Mal ganz abgesehen davon, daß Du (wie schon mehrfach erwähnt und von Dir ignoriert) schnell in Probleme läufst, wenn Du ein Frame in weniger als der Dauer eines Refreshes (1/maximale Refreshrate) übertragen willst, was dafür nämlich notwendig wäre. Oder die GPU und GSync müßten es beherrschen, den laufenden Transfer eines Frames abzubrechen. Die GPU-seitige Lösung hat diese Probleme prinzipiell nicht.
Nur möchte ich das überhaupt gar nicht. Gratulation, wie wenig du bisher von dem verstanden hast, was ich geschrieben habe. Lesekompetenz 6?

Daß es nicht um die "Ausgangslage" geht, sondern darum, was man ohne GSync-Modul im Monitor tun kann, ist an Dir vorbei gegangen? Der momentane Stand individueller Implementationen ändert nichts an prinzipiellen Sachen.
Ok, wann sehen wir dann den AMD-Wundertreiber? Sommer? Herbst? Winter? Nächstes Jahr?

Was in Deinem Szenario für die Anwendung transparent zu TripleBuffering aufgebohrt wird. Und bevor Du sagst, daß ginge nicht (das transparent für die Anwendung), OpenGL beweist das Gegenteil. Bei Deinem Szenario liegt der dritte Puffer mit dem dritten Frame nur auf dem GSync-Modul. So what?
Damit ist es es kein TripleBuffering. Next.

Es ist vorher ein Frame im Speicher und es nachher ein Frame im Speicher (des GSync-Moduls). Es wird zwischen den Speichern kopiert, was auch im VRAM der GPU eine Möglichkeit ist (nicht immer wird geflippt). Wie soll es da etwas völlig Anderes sein?
Weil nur Buffer in der GPU für Double oder TripleBuffering zählen. Next.

Es stellt in Deinem Szenario den Frontbuffer dar (das Frame zur Anzeige), aus dem das Display seine Bilddaten erhält, während die GPU zwei Backbuffer hält (keines davon wird in dem Moment zur Anzeige benutzt). Das ist per Definition TripleBuffering.
:facepalm:

Wow. Jetzt bist du schon so weit, dass die GPU deiner Behauptung nach keinen FrontBuffer mehr hat. Du bist ja echt ein Experte.

Es ist schon echt peinlich, wenn man nicht einfach zugeben kann, Blödsinn erzählt zu haben, wie du hier Gipsel?

Die Replik mit einem Netzwerkvergleich (der Raubkopien und Vervielfältigungen beinhalten würde) spare ich mir mal. ;)
Ja, spare dir das lieber. Klingt schon jetzt beim Teasern wie noch größerer Unfug wie das Zeug oben.

Du weigerst Dich also. Argumente brauchst Du nicht. Und Pi ist exakt drei. Dann wäre das also geklärt.
Argument hatte ich genug, da sowohl die von dir zitiert engl. wie auch die dt. Wikipedia dich mit dem gleichen Argument widerlegen:

TripleBuffering gilt nur innerhalb der GPU.

Punkt.

Das hatte ich hier bereits zitiert:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=10587041&postcount=2382

Keine Ahnung wie blöd man sein muss, um das jetzt immer noch zu leugnen.

Was wie erläutert unerheblich ist. Es spielt schlicht keine Rolle. Das GSync-Modul hat die Information über einen neuen Frame exakt so viel später, wie die Übertragung von der GPU dahin benötigt. Wie soll es denn da einen Timing-Vorteil bei Entscheidungen über ein anzuzeigendes Frame haben? Den gibt es nicht.
Das ist natürlich nicht unerheblich, da die Übertragung des Frames über den DP-Link schlicht nicht mehr notwendig ist.

Nenne mir doch mal ein Szenario, was davon profitieren könnte!
Zumal wie Skysnake schon anmerkte, wir hier von Zeitskalen im µs bis sub-µs-Bereich reden.
Schau dir den status quo an und du siehst es. Was muss man da noch diskutieren?

Dimitri Mayakovsky

2015-04-12, 19:42:17

Aber mir gefällt Dein (teilweise) unsachlicher Stil überhaupt nicht. Und Du negierst größtenteils Aussagen wie oben, ohne diese zu begründen bzw. zu wiederlegen. Kannst Du oder willst Du nicht?
Natürlich sind die begründet, was sollen solche Unterstellungen?

Nicht, so wie Gipsel, in GPU + Monitor. Das ist völliger Quatsch, sogar auf Wissen nach Wikipedia-Niveau.
--> Weil?
Das Wikipediazitat hatte ich gepostet:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=10587041&postcount=2382

Dass FreeSync ein Schnellschuß von AMD gegen G-Sync ist, wissen wir doch inzwischen.
--> Weil?
Weil FreeSync bei Framerates unterhalb der minimalen Panelrefreshrate auf einen grottigen VSync-Off Modus zurück fällt, hatte ich auch geschrieben:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=10583264&postcount=2166

Das Abschalten von FreeSync unterhalb der Panel-Refreshrate ist ein Fakt und kein Bullshit. Spar dir deinen Müll, nur um dich bei Gipsel einzuschleimen. Von dem kam bisher außer völlig falsch wiedergegebener Fachbegriffe und Behauptungen ohne jedes Substanz exakt gar nix.
--> Weil?
s.o. Ansonsten vergleich das PcPer-Video, wo sie das FreeSync Verhalten vorführen.

Gipsel hat Dir völlig sachlich angeboten in Kurzform darzulegen, was Deinen Knackpunkte zwischen G-Sync und Freesync sind. Dieser bist Du nicht nachgekommen, und bist auch gar nicht drauf eingegangen.
Das hatte ich bereits in meinem Ausgangsposting geschrieben (Link oben), es blamiert tatsächlich also Gipsel, dass er gar nicht weiß, worum es in der Diskussion geht.

Sieht für mich, vorsichtig ausgedrückt, "unvorteilhaft" für Dich aus. Sehr schade.
Dann hat sich diese Sichtweise jetzt ja umgekehrt. Aber netter Versuch Gipsel zur Seite zu springen, der hat das nötig :tongue:

Dimitri Mayakovsky

2015-04-12, 19:43:30

Ähm kann mich mal jemand aufklären warum LVDS eine geringere Latenz aufweisen soll als DP, wie von Dimitri Mayakovsky behauptet (natürlich ohne Beweis).

Ich habe dazu leider nichts gefunden auf die Schnelle, es ist für mich aber nicht nachvollziehbar.
Tipp: Wenn du mich nicht jedes Mal blöde von der Seite anmachen würdest, Mr. Longboard, dann könnte ich mit dir auch sachlich diskutieren.

So kannst du dir das sparen.

Und jetzt brüll wieder: "Müll, Müll, Müll!" ;D

Skysnake

2015-04-12, 19:49:09

Dimitri, warum muss ich gerade an eine Autobahn voller Geisterfahrer denken?

Grestorn

2015-04-12, 19:52:58

Skysnake

2015-04-12, 19:57:16

Es ist sehr wahrscheinlich, dass die Hardware es schon kann/können sollte. Es sind aber eben auch ASICs, und Fehler können immer mal passieren. Daher sollte man aktuell auch erstmal mit dem Erwerb eines FreeSync Monitors meiner Meinung nach warten, bis die Fragezeichen geklärt sind.

Mit dr Technik AN SICH! Worüber Gipsel, einige andere und ich selbt hier eigentlich mal geredet haben, tangiert das aber nicht.

In nem Jahr oder zwei können wir wohl sehr sicher darüber eine Aussage treffen, was heute gegangen wäre.

Unicous

2015-04-12, 19:59:09

Welche Argumentation?:confused:

Ich habe nirgends eine kohärente Aussage von ihm gelesen, Maximal vage Aussagen und Anfechtungen von Fakten und versuchte Korinthenkackerei gegenüber Gipsel.

Alles andere war nur billige Polemik.

Es wurde nicht einmal von ihm eine klar verständliche und in sich schlüssige Argumentationskette aufgebaut. Er hat es auch gar nicht versucht. Er hat nur einzelne Punkte in Gipsels Argumentationen angegriffen und darum dreht und windet er sich jetzt seit unzähligen Posts und der Redeschwall hört gar nicht mehr auf. Die Argument:ad hominem Ratio steigt unaufhörlich.

Kartenlehrling

2015-04-12, 20:00:51

Hier wird immer von verbesserte Input und Latenzen geschrieben, ich glaube immer noch das hat einfache Gründe und einer davon ist so trivial wie logisch;
Nvidia wusste es vor 2 Jahre nicht besser und "Das Modul" ermöglichte überhaupt diesen grosse Pool an kompatiblen Grafikkarten.

Trotzdem muss man sich fragen wieso funktioniert eine Gtx650-ti, aber eine gtx650 nicht oder wieso funktioniert eine GK107(650ti) aber eine GK107(640-gddr5) nicht.
Nvidia hat es einfach nur geschaft "Das Modul" als das Feature zu verkaufen und jeden zu überzeugen das es anders nicht gehen würde.

Grestorn

2015-04-12, 20:01:27

Es ist sehr wahrscheinlich, dass die Hardware es schon kann/können sollte. Woher nimmst Du diese "Wahrscheinlichkeit"? nVidia musste das auch nachbessern, nachdem das Problem bei den ersten GSync-Nachrüstmodulen sichtbar geworden ist. AMD hätte schon im Voraus, bei der Konzeption der aktuellen Chipgeneration, das Problem erkennen und sich darauf vorbereitet haben müssen.

Ich halte die AMD Ingenieure durchaus für intelligent genug, das zu tun. Aber dann wäre ich mir auch sicher, dass man sich nicht diese Blöse geben würde und das per Treiber auch nutzen würde.

Sorry, ich halte es für eher unwahrscheinlich, dass die Hardware es von sich aus kann. Man wird das vermutlich per manuellem Eingriff des Treibers hinbekommen, evtl. vom Timing etwas ungünstiger als der ASIC von nVidia das kann, andererseits glaube ich nicht, dass dieser Nachteil wirklich fühlbar sein wird.

Dimitri Mayakovsky

2015-04-12, 20:17:54

Dimitri, warum muss ich gerade an eine Autobahn voller Geisterfahrer denken?
Weil dir hunderte wild hupende Autofahrer entgegen kommen und die deine Geisterfahrermeldung im Radio hörst?

Viel Glück dann!

Ich habe nirgends eine kohärente Aussage von ihm gelesen, Maximal vage Aussagen und Anfechtungen von Fakten und versuchte Korinthenkackerei gegenüber Gipsel.
Als ob du kohärente Aussage erkennen würdest, selbst wenn sie dich in den Hintern beißen ;D

Er hat nur einzelne Punkte in Gipsels Argumentationen angegriffen und darum dreht und windet er sich jetzt seit unzähligen Posts und der Redeschwall hört gar nicht mehr auf.
Hallo, Erde an Unicous, kurzer Faktencheck:

Gipsel hat auf mein Posting geantwortet:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=10584579&postcount=2259

Bleib mal lieber bei den Fakten und hör auf mich anzusaugen, wo du es kannst. Noch drücken die Mods bei dir alle Augen zu, ob das lange hält, glaube ich aber nicht. Du hast dir locker mehr als eine Auszeit in den letzten Tagen verdient, Mr. Longboard.

Dimitri Mayakovsky

2015-04-12, 20:21:13

Woher nimmst Du diese "Wahrscheinlichkeit"? nVidia musste das auch nachbessern, nachdem das Problem bei den ersten GSync-Nachrüstmodulen sichtbar geworden ist. AMD hätte schon im Voraus, bei der Konzeption der aktuellen Chipgeneration, das Problem erkennen und sich darauf vorbereitet haben müssen.
Vorallem angesichts dessen, dass "FreeSync" ein absoluter Schnellschuss von AMD war, nachdem NVIDIA G-Sync präsentiert hat. Da hat man ein, zwei Ingenieure dran gesetzt, die haben dann kurzerhand erkannt, dass das Stromsparfeature (vgl. eDP Spec von 2008!) von DP etwas ähnliches bieten und angefangen das zu modifizieren.

Die ersten Demos, die es damals auf Laptops gab, waren wahrscheinlich allererste Alpha-Implementierungen, deshalb gab es auch nur Videos zu sehen, keine Spiele mit tatsächlich variablen Frameraten. Da hatte der Treiber wahrscheinlich nicht mal eine Logik, um eine gewisse Frametime-Vorhersage zu treffen.

Und am Verhalten im Bereich unterhalb der variablen Refreshrate, daran sieht man eben die Grenzen von AdaptiveSync.

Unicous

2015-04-12, 20:23:52

@Grestorn

Tom Peterson hat doch selbst bestätigt, dass das Modul unter anderem deswegen nötig war um eine größere Bandbreite an GPUs (Fermi u. Kepler) zu unterstützen.

Jetzt gab es unlängst den G-Sync Mobile Leak und da geht es auf einmal ohne Modul und (anscheinend) explizit nur mit Maxwell v2.

Es ist doch jetzt nicht so schwierig 1 und 1 zusammenzählen. Nvidia braucht das Modul um den potentiellen TAM zu vergrößern. Allein deswegen muss man das Modul noch ein paar Jahre mitführen.

Bei AMD ist es eine andere Ausgangssituation. Man pushed den offenen Standard weil man entsprechend geeignete Chips schon in Entwicklung bzw. auf dem Markt hat. Dass man diese Entwicklung irgendwie antizipiert hat muss man doch mal anerkennen. Bonaire XT wurde Anfang 2013 released, es kann doch innerhalb der VESA entsprechende pitches bereits gegeben haben.

Man kann Adaptive Sync/FreeSync als Schnellschuss gegen G-Sync auslegen, man kann aber auch im Gegenteil behaupten G-Sync wurde der Welt gezeigt um AMD zuvor zu kommen, weil die eigenen GPUs noch nicht die entsprechenden Funktionalität beherrscht und man auch nicht auf den Standard warten wollte der vllt. erst mit DP 1.3 oder 1.4 verabschiedet werden sollte.

Diese Theorie muss man sich auch gefallen lassen. Im Endeffekt weiß man es nicht. Es steht Behauptung gegen Behauptung. Einblicke in die inneren Zirkel kann man leider auch nicht gewinnen.

Sunrise

2015-04-12, 20:58:56

Vor allem mit dem Hintergrund, dass NV bzgl. DP generell deutlich später als AMD ankam, da hatte AMD schon etliche Generationen vorher Karten draußen, während NV maximal noch HDMI parallel zu DVI überhaupt angeboten hat.

NV hatte DP schon immer stiefmütterlich behandelt. Bis eigenartigerweise es jetzt für die Funktion für G-Sync nötig ist.

Man muss sich das mal vorstellen, AMD hatte bereits mit der HD 7870 6x miniDP-Ports (DP 1.2) an Board, während NV garnichts im Angebot hatte. Erst deutlich später kam da was auch von NV. Da merkt man eben noch AMDs Vergangenheit, die ja damals mit dem entsprechenden Ressourcen noch Multimedia-Karten gebaut hatten. Anschluss-seitig war AMD also schon immer Lichtjahre voraus.

Was außer OpenCL wohl auch für Apple ein Grund war, auf AMD zu setzen, auch wenn das nur meine persönliche Spekulation ist (Apple bietet im MacPro ja unabhängige Stream-Beschleunigung und Ausgänge per DP mit Unterstützung von hohen Auflösungen).

Mancko

2015-04-12, 21:08:41

Unicous

2015-04-12, 21:24:09

Nvidia trägt mit dieser Attitüde aber auch dazu bei dass der Markt sich nicht schneller entwickelt.

Das HDMI Konsortium hat jetzt eine HDR Spec nachgereicht. Das interessiert aber eigentlich nur die TV-Hersteller. HDMI ist aber speziell im PC Monitor-Bereich eher ein Hindernis als eine Hilfe, weil es einfach unflexibel und zu stark auf DRM ausgerichtet ist. Also nicht nutzbar für PC-Gamer.

Auch Intel hat eine ganze Weile die Sache eher behindert obwohl sie auch über die letzten Jahre immer größere Marktmacht erlangt haben und iirc erst Haswell unterstützt DP 1.2.

Es ist schon traurig wie man sich gegenseitig behindert und der Kunde ist am Ende der Verlierer.

Grestorn

2015-04-12, 21:50:31

Jetzt gab es unlängst den G-Sync Mobile Leak und da geht es auf einmal ohne Modul und (anscheinend) explizit nur mit Maxwell v2.

Meinst Du das Teil mit embedded DP? Das ist nicht vergleichbar. Dabei steuert das Grafikmodul das Panel quasi direkt, ohne Scaler.

Dimitri Mayakovsky

2015-04-12, 21:54:54

Meinst Du das Teil mit embedded DP? Das ist nicht vergleichbar. Dabei steuert das Grafikmodul das Panel quasi direkt, ohne Scaler.
Und ob es die gleichen Feature wie das G-Sync auf dem Desktop bietet, wissen wir auch noch nicht.

Unicous

2015-04-12, 21:56:42

Meinst Du das Teil mit embedded DP? Das ist nicht vergleichbar. Dabei steuert das Grafikmodul das Panel quasi direkt, ohne Scaler.

Und? :confused:

Kannst du mit Gewissheit sagen, dass Fermi und Kepler dazu in der Lage wären, das Panel so anzusteuern um VRR zu ermöglichen? Und wie sieht das mit der Funktionalität außerhalb der VRR-Range aus? Kann man die dann ohne Modul nicht abbilden, oder ist vllt. Maxwell v2 dazu schon in der Lage? Oder kann man es dann über den Treiber lösen.:wink:

Gipsel

2015-04-12, 22:48:29

/Snip
Das hatte ich hier bereits geschrieben:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=10584799&postcount=2284Da weise ich auf einen von Dir ignorierten Zusammenhang hin. Der Link zum Panel ist mit der Übertragung des alten Frames blockiert. Da kommst Du nicht drumherum.
Nein, Triple Buffering kann auch keine schon zum Monitor übertragenen Frames überspringen :facepalm:

TripleBuffering kann maximal IN DER GPU Frames überspringen. Das ist aber etwas völlig Anderes als das, was ich geschrieben habe.

Ich muss gar nichts durchdenken, weil 2+1 Buffer schlicht kein TripleBuffering ist, wie Wikipedia dir ja selbst sagt.
Für das Verhalten ist es doch scheißegal. Es gibt drei Puffer, es verhält sich exakt wie Triple Buffering, also kann man es auch so nennen. Daß Du Dich ausdrücklich weigerst, 2+1=3 zu rechnen oder die Sache zu durchdenken, ändert daran gar nichts. Wenn es nun eine APU ist und die Puffer im gemeinsamen Speicher mit dem CPU-Teil liegen (oder auch wie bei Intels Larrabee die Unterscheidung zwischen CPU- und GPU-Teil wegfällt statt dem bei Wikipedia erwähnten "Video-RAM bei Grafikkarten", nennt man das Verfahren auch so. Sich darauf zu kaprizieren, daß bei Wikipedia "Grafikkarte" steht, sich aber zu weigern, das Verhalten des Ganzen zu betrachten, kann man wohl nicht ernst nehmen.
EOD.
Ach, jetzt auf einmal, wenn sie deinen Bullshit widerlegen? ;D
Beim Auftreten des Swap-Befehls werden also die beiden Backbuffer vertauscht, während beim Auftreten von VSync der Frontbuffer und der (letzte) fertig berechnete Backbuffer vertauscht werden.
So und wo kann G-Sync jetzt im Falle eines Swap-Befehl seine Back-Buffer vertauschen? Ach stimmt, hat ja gar keine zwei Back-Buffer. Blöd. Vielleicht Front- und Back-Buffer? Ne, G-Sync hat ja nur einen Buffer. Noch blöder.

Macht wie zu erwarten keinen Sinn.Du hast es nur nicht verstanden.
Ich versuch's noch mal. Es gibt zwei Puffer auf der GPU. Wird ein neues Frame fertig, werden die natürlich geswapped. Anders geht es gar nicht, weil man ja mit dem übernächsten Frame anfangen will und die Daten irgendwo hin müssen. Das gerade fertig gewordene neue Frame wird dann zum Monitor kopiert, wo eventuell gerade noch ein Refresh aus dem Frontbuffer im GSync-Modul läuft (das ist ja Dein Szenario). Die beiden auf der GPU geswappten Buffer sind also in der Situation ganz klar Backbuffer.
Verstanden?
Weil Triple Buffering innerhalb der GPU passiert, G-Sync ja aber eben nicht.Die Frage lautete, was denn am Verhalten anders wäre und nicht, wo sich etwas verhält. ;)
Nur möchte ich das überhaupt gar nicht. Gratulation, wie wenig du bisher von dem verstanden hast, was ich geschrieben habe. Lesekompetenz 6?Doch genau das willst Du, wenn Dein Szenario vorsieht, daß zwei Frames innerhalb eines laufenden Refreshes aus dem Speicher auf dem GSync-Modul fertig werden und eines davon bereits vollständig übertragen wurde. Verstehst Du das nicht?
Kannst Dir ja mal den Zeitablauf auf ein Blatt Papier malen, wenn es anders nicht geht.
Das ist natürlich nicht unerheblich, da die Übertragung des Frames über den DP-Link schlicht nicht mehr notwendig ist.Das ist unerheblich.
Nur über DP kann das GSync-Modul erfahren, ob noch ein Frame bis zum Zeitpunkt des nächsten für das Panel erforderlichen Refresh kommt oder nicht. Die GPU weiß das also exakt so viel früher, wie die Übertragung dieser Information (also die Einleitung des Sendens des entsprechenden Frames) über DP dauert. Die GPU hat also exakt die gleichen Informationen zur Verfügung. Man gewinnt gar nichts dabei, diese Entscheidung auf dem Modul zu treffen. Deswegen spielt die Dauer für das Senden dieser Information über DP keine Rolle, es ändert nichts am Ausgang des Entscheidungsprozesses.
Schau dir den status quo an und du siehst es. Was muss man da noch diskutieren?Dir fällt also kein Szenario ein, bei dem die geringere "Latenz" zum Panel eine Rolle spielen könnte.

Btw., Latenz spielt nur für bidirektionale Kommunikation in irgendeiner Form eine Rolle. Die Bilddatenlinks sind typischerweise unidirektional (insbesondere auch bei DP, nur der AUX-Channel ist bidirektional, da geht aber für die Bilddarstellung nix drüber), zumal bei A-Sync auch keine Kommunikation vom Panel bzw. dem Scaler zur GPU für jedes Frame nötig ist. G-Sync hat laut einigen Artikeln darüber das Bedürfnis zur bidirektionalen Kommunikation zwischen GPU und GSync-Modul (das Panel muß eigentlich auch nichts zum GSync-Modul zurückmelden, die angeblich niedrigere Latenz des LVDS-Links ist also hier ebenso völlig egal, das Panel ist schlicht nur eine Senke für die Bilddaten). Für Handshakes bei jedem Frame spielt also die Latenz von DP eine kleine Rolle (kommt daher der kleine negative Einfluß auf die Performance?), nicht bei ASync.
Nur mal so ganz nebenbei.

Dimitri Mayakovsky

2015-04-12, 23:08:37

Da weise ich auf einen von Dir ignorierten Zusammenhang hin. Der Link zum Panel ist mit der Übertragung des alten Frames blockiert. Da kommst Du nicht drumherum.
Spielt nur leider für meine Betrachtung gar keine Rolle. Aber geschenkt.

Für das Verhalten ist es doch scheißegal. Es gibt drei Puffer, es verhält sich exakt wie Triple Buffering, also kann man es auch so nennen. Daß Du Dich ausdrücklich weigerst, 2+1=3 zu rechnen oder die Sache zu durchdenken, ändert daran gar nichts. Wenn es nun eine APU ist und die Puffer im gemeinsamen Speicher mit dem CPU-Teil liegen (oder auch wie bei Intels Larrabee die Unterscheidung zwischen CPU- und GPU-Teil wegfällt statt dem bei Wikipedia erwähnten "Video-RAM bei Grafikkarten", nennt man das Verfahren auch so. Sich darauf zu kaprizieren, daß bei Wikipedia "Grafikkarte" steht, sich aber zu weigern, das Verhalten des Ganzen zu betrachten, kann man wohl nicht ernst nehmen.
EOD.
Gipsel, es ändert nichts daran, dass das Verhalten von G-Sync kein TripleBuffering ist. Punkt. Siehe mein Beispiel mit dem Netzwerk. Sobald du einen externen Bus (wie DP) dazwischen hast, kannst du schlicht nicht mehr von TripleBufferin reden. Das ist gröbster Unfug und zeigt nur, dass du nicht in der Lage bist Fachbegriffe konkret anzuwenden.

Du hast es nur nicht verstanden.
Ich versuch's noch mal. Es gibt zwei Puffer auf der GPU. Wird ein neues Frame fertig, werden die natürlich geswapped. Anders geht es gar nicht, weil man ja mit dem übernächsten Frame anfangen will und die Daten irgendwo hin müssen. Das gerade fertig gewordene neue Frame wird dann zum Monitor kopiert, wo eventuell gerade noch ein Refresh aus dem Frontbuffer im GSync-Modul läuft (das ist ja Dein Szenario). Die beiden auf der GPU geswappten Buffer sind also in der Situation ganz klar Backbuffer.
Verstanden?
Generell meint man bei Grafikkarten mit dem Back-Buffer den Buffer, oder auch meinetwegen die Buffer, die aktuell nicht ausgelesen werden, um selbige Daten zum Monitor zu schicken. Front Buffer ist eben jener Buffer, von dem aus das Bild über einen externen Bus an das Display geschickt werden.

Deine Theorie ist inzwischen dermaßen krude, dass die GPU gar keinen Frontbuffer mehr hat, aus dem ein Frame an den Monitor geschickt werden kann :facepalm:

Die Frage lautete, was denn am Verhalten anders wäre und nicht, wo sich etwas verhält. ;)
Wie das Verhalten ist hatte ich bereits erläutert. Ändert nur nichts an deinem falschen Gebrauch von Fachtermini.

Doch genau das willst Du, wenn Dein Szenario vorsieht, daß zwei Frames innerhalb eines laufenden Refreshes aus dem Speicher auf dem GSync-Modul fertig werden und eines davon bereits vollständig übertragen wurde. Verstehst Du das nicht?
Jetzt ist der Gipsel schon so weit, dass die Frames aus dem Speicher auf dem G-Sync Modul fertig werden. Was auch immer der Autor uns damit sagen will ;D

Das ist unerheblich.
Nur über DP kann das GSync-Modul erfahren, ob noch ein Frame bis zum Zeitpunkt des nächsten für das Panel erforderlichen Refresh kommt oder nicht. Die GPU weiß das also exakt so viel früher, wie die Übertragung dieser Information (also die Einleitung des Sendens des entsprechenden Frames) über DP dauert. Die GPU hat also exakt die gleichen Informationen zur Verfügung. Man gewinnt gar nichts dabei, diese Entscheidung auf dem Modul zu treffen. Deswegen spielt die Dauer für das Senden dieser Information über DP keine Rolle, es ändert nichts am Ausgang des Entscheidungsprozesses.
Dir fällt also kein Szenario ein, bei dem die geringere "Latenz" zum Panel eine Rolle spielen könnte.
Natürlich, das Szenario hatte ich hier bereits ausgeführt. Es gibt auch gar nicht (das hast du offensichtlich immer noch null verstanden) darum, was die GPU an Informationen hat - sondern was der Monitor an Informationen hat!

Btw., Latenz spielt nur für bidirektionale Kommunikation in irgendeiner Form eine Rolle. Die Bilddatenlinks sind typischerweise unidirektional (insbesondere auch bei DP, nur der AUX-Channel ist bidirektional, da geht aber für die Bilddarstellung nix drüber), zumal bei A-Sync auch keine Kommunikation vom Panel bzw. dem Scaler zur GPU für jedes Frame nötig ist. G-Sync hat laut einigen Artikeln darüber das Bedürfnis zur bidirektionalen Kommunikation zwischen GPU und GSync-Modul (das Panel muß eigentlich auch nichts zum GSync-Modul zurückmelden, die angeblich niedrigere Latenz des LVDS-Links ist also hier ebenso völlig egal, das Panel ist schlicht nur eine Senke für die Bilddaten). Für Handshakes bei jedem Frame spielt also die Latenz von DP eine kleine Rolle, nicht bei ASync.
Nur mal so ganz nebenbei.
Immerhin hast du aufgehört den Blödsinn zu behaupten, dass G-Sync "exakt die gleiche Sache" nutzt wie A-Sync, denn jetzt hat G-Sync plötzlich eine Kommunikationsschnittstelle, die A-Sync nicht besitzt.

Es geht also voran, hat ja nur drei Tage gedauert ;D

Gipsel

2015-04-12, 23:33:19

Dimitri ist nicht alleine mit seiner Meinung. Ich seh das zwar nicht so kompromisslos und denke immer noch, dass AMD eine nahezu äquivalente Lösung per Treiber hinbekommen kann (auch wenn ich nicht glaube, dass die HW bereits dafür vorbereitet ist, wie Gipsel behauptet), aber im Grundsatz hat er m.E. schon recht mit seiner Argumentation.Mit was genau? Daß irgendwelche niedrigeren Latenzen dem GSync-Modul helfen würden? Das ist nicht so. Oder fällt Dir eine Gelegenheit ein, wo das der Fall wäre?
Meinst Du das Teil mit embedded DP? Das ist nicht vergleichbar. Dabei steuert das Grafikmodul das Panel quasi direkt, ohne Scaler.Wirkliche Direktsteuerung des Panels wären DirectDrive-Monitore (DDM) dafür gibt es auch eine Spec. Link zum Timingcontroller des Panels (also nur Scaler weglassen) geht mit eDP, da hat der Panelcontroller dann ein eDP-Interface statt LVDS (FPD-Link). Einige Mobilchips haben/hatten ja direkt LVDS-Interfaces für die Anzeige, mit eDP kann man halt einen der normalen DP-Links auf dem Chip benutzen (mindestens einer davon kann für normales DP oder in Notebooks eben für eDP konfiguriert werden, die anderen für externe Displays laufen weiter im normalen DP-Mode).

Grestorn

2015-04-12, 23:49:00

Mit was genau? Daß irgendwelche niedrigeren Latenzen dem GSync-Modul helfen würden? Das ist nicht so. Oder fällt Dir eine Gelegenheit ein, wo das der Fall wäre?

Ich hab schon mehrfach geschrieben, dass ich es für einen ziemlichen Unterschied halte, wenn der Treiber selbst Wiederholframes anstoßen muss im Vergleich zum ASIC im GSync Modul. Das sind Welten was die Reaktionszeit angeht, wenn es sich in der Praxis vielleicht auch nur kaum merkbar auswirken wird.
Ich bewege mich zugegebenermaßen auf dünnem Eis, da ich beruflich nicht selbst FPGAs programmiere sondern nur mit Leuten zusammenarbeite, die eben das tun. Aber ich weiß eben auch, wieviel einfacher es ist, Echtzeitanforderungen mit FPGA umzusetzen als mit dem PC, und wenn man dann noch die Kette an zusätzlichen Komponenten ansieht - eine davon eine Datenschnittstelle - DP -, die Daten über mehrere Meter Entfernung überträgt - dann ist eigentlich ganz klar, dass das nicht ohne Folgen bleiben kann.

Es geht ja auch nicht darum, dass Frame einfach nach Überschreiten der maximalen Standzeit eines Frames einzufügen. Um eben Nachteile zu vermeiden, müssen die aktuellen Frametimes analysiert werden, so dass die Wiederholframes möglichst optimal und gleichverteilt in die berechneten Frames eingefügt werden. Diese Berechnung ist mathematisch recht einfach, aber vom Treiber dennoch eher schwer in Echtzeit zu bewerkstelligen. Für den FPGA ist das dagegen ein Witz.

Aber wie gesagt, es kann gut sein, dass diese Folgen überhaupt nicht relevant sind in der Praxis. Man wird sehen. Es kann aber auch sein, dass AMD das Problem auf diesem Weg überhaupt nicht in den Griff bekommt - auch wenn ich selbst das für eher unwahrscheinlich halte. Aber was weiß ich schon von den Problemen, mit denen die Ingenieure konfrontiert werden? Was wissen wir allesamt darüber?

Und Angesichts dieser Tatsache täte uns allen glaube ich ein wenig mehr Demut und Zurückhaltung in der Diskussion gut :)

Gipsel

2015-04-13, 00:12:16

Spielt nur leider für meine Betrachtung gar keine Rolle. Aber geschenkt.

Gipsel, es ändert nichts daran, dass das Verhalten von G-Sync kein TripleBuffering ist. Punkt. Siehe mein Beispiel mit dem Netzwerk. Sobald du einen externen Bus (wie DP) dazwischen hast, kannst du schlicht nicht mehr von TripleBufferin reden. Das ist gröbster Unfug und zeigt nur, dass du nicht in der Lage bist Fachbegriffe konkret anzuwenden.

Generell meint man bei Grafikkarten mit dem Back-Buffer den Buffer, oder auch meinetwegen die Buffer, die aktuell nicht ausgelesen werden, um selbige Daten zum Monitor zu schicken. Front Buffer ist eben jener Buffer, von dem aus das Bild über einen externen Bus an das Display geschickt werden.

Deine Theorie ist inzwischen dermaßen krude, dass die GPU gar keinen Frontbuffer mehr hat, aus dem ein Frame an den Monitor geschickt werden kann :facepalm:

Wie das Verhalten ist hatte ich bereits erläutert. Ändert nur nichts an deinem falschen Gebrauch von Fachtermini.

Jetzt ist der Gipsel schon so weit, dass die Frames aus dem Speicher auf dem G-Sync Modul fertig werden. Was auch immer der Autor uns damit sagen will ;D

Natürlich, das Szenario hatte ich hier bereits ausgeführt. Es gibt auch gar nicht (das hast du offensichtlich immer noch null verstanden) darum, was die GPU an Informationen hat - sondern was der Monitor an Informationen hat!

Immerhin hast du aufgehört den Blödsinn zu behaupten, dass G-Sync "exakt die gleiche Sache" nutzt wie A-Sync, denn jetzt hat G-Sync plötzlich eine Kommunikationsschnittstelle, die A-Sync nicht besitzt.

Es geht also voran, hat ja nur drei Tage gedauert ;DDas wird ja immer absonderlicher.

An der EOD bezüglich TripleBuffering ändere ich nichts. Ich habe ausführlich beschrieben, wie das in Deinem Szenario abläuft und welche Funktion welcher Buffer dann hat. Das kann jeder selber nachlesen und dann nachdenken (um dann zu dem Schluß zu kommen, daß es genau das ist).
Deine in einem Post explizit geäußerte Weigerung, das zu tun, erübrigt jede weitere Diskussion um den Punkt.

Weiterhin stelle ich fest, die deutsche Sprache immer noch schwer ist. Also muß wieder mal die farbliche Kennzeichnung von grammatikalischen Konstrukten her:
"Doch genau das willst Du, wenn Dein Szenario vorsieht, daß zwei Frames innerhalb eines laufenden Refreshes aus dem Speicher auf dem GSync-Modul fertig werden und eines davon bereits vollständig übertragen wurde. Verstehst Du das nicht?"
Hilft das vielleicht?

Bezüglich der Latenzvorteile hast Du kein Beispiel oder Gegenargument zu meinen Ausführungen geliefert, daß eine wie auch immer geartete "Latenz" der Datenübertragung über DP keine Rolle spielt, da sie ASync und GSync in exakt gleichem Maße Weise beeinflußt. Erkläre mir doch ein Szenario, wo das GSync-Modul prinzipiell mehr wissen kann oder besser wissen kann als die GPU, welches Frame anzuzeigen ist oder irgendeinen Timing-Vorteil hat. Die GPU kann prinzipiell mit exakt den gleichen Informationen arbeiten und exakt die gleichen Entscheidungen über die anzuzeigenden Frames treffen. Nur für bidirektionale Kommunikation ist die Latenz von Interesse. Da die Bilddarstellung bei ASync eine solche nicht beinhaltet, war's das.
Wenn ein neuer Refresh eingeleitet werden muß und das nächste fertige Frame kommt ein ganz kleines bißchen zu spät dafür, tut es das bei ASync genau wie bei GSync (mit einer eventuellen zusätzlichen Penalty für GSync wegen der Handshakes, weil da spielt die Latenz tatsächlich eine Rolle). Bei ASync wird die Entscheidung nur ein paar µs früher getroffen, weil dort schlicht immer alle Informationen ein paar µs früher da sind und auch alle Deadlines für Entscheidungen um genau diese Zeitspanne früher ablaufen. Die GPU ist dem GSync-Modul sozusagen zeitlich ein paar µs voraus. ;)

Gipsel

2015-04-13, 01:13:19

Ich hab schon mehrfach geschrieben, dass ich es für einen ziemlichen Unterschied halte, wenn der Treiber selbst Wiederholframes anstoßen muss im Vergleich zum ASIC im GSync Modul. Das sind Welten was die Reaktionszeit angeht, wenn es sich in der Praxis vielleicht auch nur kaum merkbar auswirken wird.Wie schon mal geschrieben, die GPU ist ein ASIC (FPGA eigentlich nicht, aber egal). Und die Wiederholframes werden ziemlich sicher per Hardwaretimer angestoßen, da nimmt man schlicht den, der das bei festen Refreshraten auch macht (nur programmiert auf die minimale Refreshrate und automatisch bei jedem Refreshzyklus resettet statt frei laufend).
Was vermutlich in der momentanen Ausführung bei AMD nicht in Hardware mit drin ist, ist eine clevere Logik zur Vermeidung der Kollisionen eines neuen Frames mit einem Zwangsrefresh. Das müßte AMD per Treiber reinbasteln. Wäre praktisch das Setzen des Konfigurationsregisters für die Zeitdauer bis zum nächsten Zwangsrefresh, den setzt man dann schlicht auf die Hälfte der Frametime des letzten Frames, wenn sich die Frametime der unteren Grenze nähert (und paßt es laufend an). Was anderes macht GSync auch nicht (die besagte Halbierung ist exakt der Grund, warum Frames verdoppelt, vervierfacht, verachtfacht werden, also immer Zweierpotenzen angezeigt werden ;)).
Ich bewege mich zugegebenermaßen auf dünnem Eis, da ich beruflich nicht selbst FPGAs programmiere sondern nur mit Leuten zusammenarbeite, die eben das tun. Aber ich weiß eben auch, wieviel einfacher es ist, Echtzeitanforderungen mit FPGA umzusetzen als mit dem PC,Das ist genau der Grund, weswegen im PC die Refreshzyklen auch per Hardwaretimer angestoßen werden. ;)
und wenn man dann noch die Kette an zusätzlichen Komponenten ansieht - eine davon eine Datenschnittstelle - DP -, die Daten über mehrere Meter Entfernung überträgt - dann ist eigentlich ganz klar, dass das nicht ohne Folgen bleiben kann.Die Verzögerung über die Kabel ist konstant und spielt für das Timing eigentlich keine Rolle. Wenn Du am Anfang des Kabels exakt alle 33,333ms einen Refresh startest, tut man das am Ende des 10m langen Kabels auch. Zeitabstände ändern sich nicht.
Es geht ja auch nicht darum, dass Frame einfach nach Überschreiten der maximalen Standzeit eines Frames einzufügen. Um eben Nachteile zu vermeiden, müssen die aktuellen Frametimes analysiert werden, so dass die Wiederholframes möglichst optimal und gleichverteilt in die berechneten Frames eingefügt werden. Diese Berechnung ist mathematisch recht einfach, aber vom Treiber dennoch eher schwer in Echtzeit zu bewerkstelligen. Für den FPGA ist das dagegen ein Witz.
Angenommen man mißt die Frametime in den gleichen Zyklen (Integer) mit denen man den Refreshtimer programmiert, sieht mir der Aufwand sehr bescheiden aus. In etwa so:
Langvariante:

if (frametime>threshold)
{
early_refresh_enabled=true;
Set_refresh_timer_reg(frametime/(frametime/threshold+1));
}else if (early_refresh_enabled)
{
Set_refresh_timer_reg(max_refresh_time);
early_refresh_enabled=false;
}

Kurzversion:

if (frametime>threshold) Set_refresh_timer_reg(frametime/(frametime/threshold+1)) else Set_refresh_timer_reg(max_refresh_time);
Das Ding macht sogar nicht nur die sture Halbierung der Frametime für das Anzeigeintervall, sondern rechnet das genauer aus, wieviele Wiederholungen man vermutlich benötigt ;).
Allgemein muß man vermutlich noch die Einheiten umrechnen. Ist dann also vermutlich eine Multiplikation mehr. Das ganze in die Routine gehängt, die bei jedem Bufferflip aufgerufen wird (irgendwie muß ja der GPU verklickert werden, daß ein neues Frame fertig ist) und fertig ist der Lack.
Die eigentliche Frage ist, wie schnell der Zugriff auf das Register zum Konfigurieren der maximalen Dauer zwischen den Refreshes ist und ob man den so einfach im laufenden Betrieb ändern darf (und nicht z.B. nur beim Wechsel von Anzeigemodis). Da kommt es darauf an, wie das im Detail implementiert ist. Das weiß außerhalb AMDs wohl gerade keiner so ganz genau.
Allerdings sind viele Register für das Timing oder anderer Parameter der Displayengines offenbar on-the-fly änderbar, zumindest wenn es nach den Manuals für die alte R600-Generation geht (okay ist alt, aber unflexibler dürften die Displayengines nicht geworden sein, für die neueren GPUs, gibt es die Doku afaik nicht öffentlich). Einige Register können sich nur zwischen zwei Frames ändern, andere nur zwischen jeder Zeile des Frames, also alle paar µs (da steht explizit dran, daß man die mehrfach pro Frame ändern kann) und bei anderen kann man offenbar konfigurieren, wann die Änderung wirksam wird (z.B. mit dem nächsten Refresh oder mit der nächsten Zeile oder sofort).

Dimitri Mayakovsky

2015-04-13, 09:42:41

Das wird ja immer absonderlicher.
Stimmt, ist es tatsächlich, was du hier behauptest.

An der EOD bezüglich TripleBuffering ändere ich nichts. Ich habe ausführlich beschrieben, wie das in Deinem Szenario abläuft und welche Funktion welcher Buffer dann hat. Das kann jeder selber nachlesen und dann nachdenken (um dann zu dem Schluß zu kommen, daß es genau das ist).
Es ist trotzdem falsch und widerspricht auch dem, was deine eigenen Quellen sagen. TripleBuffering ist einfach der falsche Fachterm. Punkt. Inzwischen hat (deine Behauptung) die GPU gar keinen Frontbuffer mehr für die Frameübertragung an das Display, obwohl zumindest die Übertragung des Frames identisch zu DP ist.

Das macht schlicht keinen Sinn.

Deine in einem Post explizit geäußerte Weigerung, das zu tun, erübrigt jede weitere Diskussion um den Punkt.
Ja ich weigere mich auch dir zuzustimmen, wenn du morgen behauptest deine Grafikkarte "verbrauche Strom". Aber nur deswegen, weil es Blödsinn ist.

Weiterhin stelle ich fest, die deutsche Sprache immer noch schwer ist. Also muß wieder mal die farbliche Kennzeichnung von grammatikalischen Konstrukten her:
"Doch genau das willst Du, wenn Dein Szenario vorsieht, daß zwei Frames innerhalb eines laufenden Refreshes aus dem Speicher auf dem GSync-Modul fertig werden und eines davon bereits vollständig übertragen wurde. Verstehst Du das nicht?"
Hilft das vielleicht?
So macht es tatsächlich Sinn, blöd formuliert, aber was solls.

Nur macht es immer noch keinen Sinn bei einem bereits aus dem FrontBuffer an das Display gesendenten Frame jetzt plötzlich von TripleBuffering zu sprechen. Das erzeugt ja noch dazu entsprechende Latenzen und InputLag, weil das gerade gezeigte Bild immer zwei Frames alt ist.

Das ist bei G-Sync das völlige Gegenteil, wenn dem so wäre müsste der InputLag unterhalb der minimalen Panelrefreshrate ja plötzlich hochgehen.

Bezüglich der Latenzvorteile hast Du kein Beispiel oder Gegenargument zu meinen Ausführungen geliefert
Vielleicht solltest du dich weniger über irgendwelche grammatikalischen Konstruktionen wie oben auslassen, wenn du meine bisherigen Postings nicht mal verstanden (hast du sie überhaupt gelesen?) hast.

Obiges Beispiel hat ja auch schon gezeigt, dass du es gar nicht verstanden hast.

Gipsel

2015-04-13, 09:58:39

So macht es tatsächlich Sinn, blöd formuliert, aber was solls.

Nur macht es immer noch keinen Sinn bei einem bereits aus dem FrontBuffer an das Display gesendenten Frame jetzt plötzlich von TripleBuffering zu sprechen. Das erzeugt ja noch dazu entsprechende Latenzen und InputLag, weil das gerade gezeigte Bild immer zwei Frames alt ist.

Das ist bei G-Sync das völlige Gegenteil, wenn dem so wäre müsste der InputLag unterhalb der minimalen Panelrefreshrate ja plötzlich hochgehen.Nur erzeugt es kein zusätzliches Lag (die Verzögerung bei der Kollision mit einem laufenden Refresh ist ja unvermeidlich, egal ob man double oder triple buffering macht, man erhöht mit dem beschriebenen triple buffer Vorgehen nur die Performance des nächsten Frames). Denk noch mal genauer darüber nach! ;)
Vielleicht solltest du dich weniger über irgendwelche grammatikalischen Konstruktionen wie oben auslassen, wenn du meine bisherigen Postings nicht mal verstanden (hast du sie überhaupt gelesen?) hast.

Obiges Beispiel hat ja auch schon gezeigt, dass du es gar nicht verstanden hast.Da Du was von erhöhtem Input-Lag und der Anzeige von zwei Frames alter Bild erzählst, hat wohl irgendwer anders etwas noch nicht verstanden :wink:. Ich habe doch lediglich beschrieben, wie man das Verhalten in dem von Dir aufgestellten Szenario erreicht, und das man dafür mitnichten zwingend ein Modul im Monitor benötigt, ja daß es sogar Einschränkungen mit sich bringen kann (für das von Dir postulierte Überspringen von Frames).

Dimitri Mayakovsky

2015-04-13, 10:07:10

Nur erzeugt es kein zusätzliches Lag (die Verzögerung bei der Kollision mit einem laufenden Refresh ist ja unvermeidlich, egal ob man double oder triple buffering macht, man erhöht mit dem beschriebenen triple buffer Vorgehen nur die Performance des nächsten Frames). Denk noch mal genauer darüber nach! ;)
Triple Buffering erzeugt grundsätzlich Lag, weil die GPU nicht den gerade fertig gestellten Frame anzeigt, sondern den davor fertig gestellten. Im Falle von DoubleBuffering wird der gerade als letztes fertig gestellte Frame anzeigt.

Latenz also + 1 Frame.

Demgegenüber kann G-Sync dynamisch den letzten fertig gestellten Frame wählen, ist also nicht an das starre Konzept von TripleBuffering gebunden - das hatte ich aber schon vor 10 Postings geschrieben.

Ja, im Falle einer Kollision fügt auch G-Sync Latenz hinzu, das ist aber anders nicht möglich, ohne visuelle Bildartefakte zu haben.

Da Du was von erhöhtem Input-Lag und der Anzeige von zwei Frames alter Bild erzählst, hat wohl irgendwer anders etwas noch nicht verstanden :wink:. Ich habe doch lediglich beschrieben, wie man das Verhalten in dem von Dir aufgestellten Szenario erreicht, und das man dafür mitnichten zwingend ein Modul im Monitor benötigt, ja daß es sogar Einschränkungen mit sich bringen kann (für das von Dir postulierte Überspringen von Frames).
Dass ist deine Behauptung, die darfst du gerne aufstellen, nur ist sie unbewiesen. Und der aktuelle status quo widerlegt deine Behauptung. Solange uns AMD keine FreeSync-Implementierung zeigt, die ein FrameDoubling ala G-Sync durchführt, ist es leider nur eine unbewiesen Behauptung von dir.

Es gibt mehr als genug Punkte, an denen die Hardware in den GPUs nicht so funktioniert, wie sie es für volle G-Sync Funktionalität über A-Sync müsste.

Gipsel

2015-04-13, 11:30:43

Triple Buffering erzeugt grundsätzlich Lag, weil die GPU nicht den gerade fertig gestellten Frame anzeigt, sondern den davor fertig gestellten. Im Falle von DoubleBuffering wird der gerade als letztes fertig gestellte Frame anzeigt.

Latenz also + 1 Frame.Das ist falsch, erst recht in Kombination mit variablen Refreshraten (denn da wird der dritte Puffer nur bei Kollisionen eines neuen Frames mit einem Refresh genutzt, ansonsten triggert natürlich die Fertigstellung eines neuen Frames auch den Transfer eben dieses Frames).
Ja, im Falle einer Kollision fügt auch G-Sync Latenz hinzu, das ist aber anders nicht möglich, ohne visuelle Bildartefakte zu haben.Was in dem von Dir gezeichneten Szenario eben genau Triple Buffering darstellt.
Dass ist deine Behauptung, die darfst du gerne aufstellen, nur ist sie unbewiesen.Du kannst oder willst sie nur nicht nachvollziehen. Andere offenbar schon. Ausführlich genug dargelegt habe ich sie.
Wie war das nochmal mit dem Überspringen eines Frames im GSync-Modul und den dafür nötigen Frametimes bzw. Übertragungsgeschwindigkeit? Du erinnerst Dich? Das war die Passage, in der ich Dir in einem Satz die Struktur farblich markieren mußte, damit Du den Sinn erfassen und ihm dann schlußendlich zustimmen konntest? Du hattest also ganz offenbar die Anforderungen und deren Auswirkungen in Deinem eigenen Beispiel nicht überblickt.

Meine Ausführungen sind schlüssig. Du darfst gerne konkret nachfragen, warum etwas so sein soll, wie ich sage. Ich beantworte Dir das ;).
Und wenn es "mehr als genug" Punkte gibt, die man mit ASync prinzipiell nicht machen kann, um Feature-Parität mit G-Sync zu bekommen, dürfte es Dir sicher nicht schwerfallen, davon den einen oder anderen zu nennen.
Latenz-Vorteil? Nope.
Framedoubling? Nope.
Triple Buffering (oder 2+1 Buffering in "Dima-Speak" ;))? Nope.
Was noch?

robbitop

2015-04-13, 11:49:44

fondness

2015-04-13, 11:53:52

Ich sehe viel mehr das praktische Problem das AMD aufgrund des offenen Standards keine Specs vorgeben kann und deshalb viele Monitor ungeeignet sind für Framedoubeling. Bei allen nicht 144hz Monitoren kann man sich das wohl sparen, gerade wenn es keine deutlich niedrigere minimale Refresh-Rate gibt.

robbitop

2015-04-13, 11:58:38

Naja man könnte es aber als Voraussetzung für die Zertifizierung nach FreeSync vorgeben. Und warum sollten sie ungeeignet sein? Gipsel hat doch hier beschrieben, dass es eigentlich nur eine Voraussetzung der Grafikkarte und des Treiber ist und das über DP geschehen würde.

Sunrise

2015-04-13, 12:00:48

Wenn man tatsächlich Feature-Parität per Treiber realisieren kann (untere fps Grenze -> Frames werden verdoppelt bei G-Sync - bei A-Sync geht es in den VSync On/off mode ohne variablen Refresh) - dann ist es wirklich leider typisch AMD. Halbfertige Dinge releasen statt eine wirklich vollständige wasserdichte Sache später zu releasen. Genau das gleiche wie mit VSR oder Crossfire (seit Frame Pacing wirklich gut nutzbar) und noch anderen zahlreichen Dingen.

Das tut dem Ruf nicht gut - Ersteindrücke sind so wichtig.
Das eine ist die Unterstützung für A-Sync, das andere ist eine gewisse Feature-Parität (ist die überhaupt gewollt, evtl. will AMD eine eigene Lösung anbieten...), das ist also etwas ganz anderes.

FreeSync hält sich da wohl noch sehr strikt an den Standard, G-Sync macht "was es will".

Natürlich war die Vorstellung dennoch nicht perfekt, NV hat da auch deutlich mehr Geld in die Hand genommen und mehr Tamm-Tamm gemacht. Im Endeffekt wurde sich seitens NV einfach mehr darum gekümmert eine gute Lösung auch schneller am Markt zu haben.

Das mit dem Ersteindruck stimmt natürlich dennoch.

Naja man könnte es aber als Voraussetzung für die Zertifizierung nach FreeSync vorgeben. Und warum sollten sie ungeeignet sein? Gipsel hat doch hier beschrieben, dass es eigentlich nur eine Voraussetzung der Grafikkarte und des Treiber ist und das über DP geschehen würde.
Man könnte vieles (sie machen es aber nicht, evtl. weil Ressourcen stark limitiert, niemand stellt sich die entscheidenden Fragen, auch war die Execution selten so gut wie bei NV...).

NV hat den Monitorherstellern viel Arbeit abgenommen, hier muss AMD aktuell einen deutlichen schwierigeren Weg gehen. Das ist ein Lernprozess auf beiden Seiten.

Unicous

2015-04-13, 12:06:08

@robbitop

Wenn sie das getan hätten, dann gäbe es jetzt einen riesigen shitstorm weil AMD ihr Versprechen, dass es FreeSync im Q1'15 geben wird, gebrochen hätte.

Sie hätten es im Endeffekt also niemandem Recht gemacht. Und FreeSync ist sicherlich nicht Priorität 1 im Unternehmen und dazu ist scheint die manpower auch knapp zu sein.

Dass die Hersteller nur 0815-Modelle und Panels nutzen, konnte man vorher auch nicht wissen. Dass LG ein Panel nutzt dessen Range dümmliche 48-75 Hz ausweist zeigt wie engagiert die Hersteller an die Sache herangehen. Asus scheint das etwas anders zu sehen und gibt sich augenscheinlich mehr Mühe (oder alternativ haben sie geschlafen:tongue:).

Es gibt auch noch die kleine Bude Nixeus. Die wollen auch einen Standard 24"er TN mit 144 Hz im Q2 bringen. Den wird man hierzulande bloß nicht kaufen können, schätze ich.

Um die iiyama Sache ist es sehr still geworden, von Viewsonic hört man auch nichts.
Ich schätze die sind in Lauerstellung, wie es angenommen wird.

robbitop

2015-04-13, 12:08:43

Tja und damit entscheiden sich dann viele für G-Sync. Bei mir ist die Entscheidung auch glasklar - zumindest wenn die Situation so bleibt, wie sie ist. :(

fondness

2015-04-13, 12:08:49

Naja man könnte es aber als Voraussetzung für die Zertifizierung nach FreeSync vorgeben.

Man kann ohnehin niemanden daran hindern einen Adaptive-Sync-Monitor mit anderen Specs auf den Markt zu bringen, den deshalb nicht zu unterstützen wäre ungeschickt.

Und warum sollten sie ungeeignet sein? Gipsel hat doch hier beschrieben, dass es eigentlich nur eine Voraussetzung der Grafikkarte und des Treiber ist und das über DP geschehen würde.

Ja gehen würde es natürlich, aber wie schon mehrmals erwähnt wäre das wohl eher nicht so sinnvoll. Aber muss man sich in der Praxis ansehen.

Unicous

2015-04-13, 12:12:48

Tja und damit entscheiden sich dann viele für G-Sync. Bei mir ist die Entscheidung auch glasklar - zumindest wenn die Situation so bleibt, wie sie ist. :(

Es entscheiden sich allein schon deswegen "viele" (wie viele weiß man nicht) für G-Sync weil Nvidia einen deutlich höheren Marktanteil hat. Besonders im HighEnd- Enthusiastenbereich, wo man auch mal 800 Euro für einen Monitor ausgibt.:wink:

robbitop

2015-04-13, 12:16:04

Und daran muss AMD was ändern. Das geht IMO nur über den Ruf. Halbfertiges Zeug hilft da nicht.

fondness

2015-04-13, 12:49:48

Tja und damit entscheiden sich dann viele für G-Sync. Bei mir ist die Entscheidung auch glasklar - zumindest wenn die Situation so bleibt, wie sie ist. :(

Warum genau? Weil sie 100EUR mehr bezahlen wollen für ein proprietäres NV-Feature das man genau so über den DP-Standard bekommen kann? Dann sollen sie doch, aber dann bitte nachher nicht jammern. Ja NV war um ein paar Monate früher dran und ja AMD sollte noch das Framedoubeling implementieren, aber das wars dann auch schon. Grundsätzlich funktioniert FreeSync um nichts schlechter, entgegen mancher Horrorgeschichten von wegen das syncen geht nicht ohne Modul. Der AMD-Ansatz wäre IMO gerade für den Kunden die sinnvollere Alternative.

robbitop

2015-04-13, 13:04:12

Ihm fehlt wie gesagt das Framedoubling Feature. Das würde mich stören. Monitor ist auch schnell wieder verkauft und getauscht. Zumindest bei mir. :)

Tesseract

2015-04-13, 13:10:52

TripleBuffering überspringt auch dann keinen Frame, wenn es nicht notwendig ist. Heißt: Wenn A der Frontbuffer ist, in B ein Frame liegt und die GPU gerade in C mit Rendern fertig ist, wird trotzdem der Frame aus B genommen, obwohl man den aus C nehmen könnte. Dies ist bei G-Sync genau anders, in dieser Konstellation würde G-Sync C nehmen. Eben kein Statisches TripleBuffering.

was soll "statisches triple buffering" sein? es gibt im prinzip 2 gängige varianten: klassicher triple buffer und render ahead. render ahead ist ein ring buffer bei dem die frames nacheinander ausgegeben werden, triple buffer rendert abwechselnd in beide back buffer und sobald der bufferswap erfolgt wird der backbuffer mit dem aktuellsten fertigen frame zum neuen front buffer - das entspricht in deinem beispiel dem C. der grund warum DX render ahead verwendet ist weil MS das so festgelegt hat, lösungen wie gsync oder async sitzen aber auf einem anderen abstraktionslayer und können implementieren was sie wollen weil sie die synchronisation vor der 3D-API verbergen. aus sicht von d3d oder ogl ist async/gsync "unsynchonisiert". auf GPU-seite unterhalb von X fps einen klassischen triple buffer zuzuschalten sollte ziemlich trivial sein.

Unicous

2015-04-13, 13:14:57

@robbitop

Ja, bei dir. Aber nicht jeder tauscht alle paar Wochen Monitor und GPU aus. Und es gibt genug Enthusiasten die sich ein Paket schnüren lassen und dass dann beim Händler ihres Vertrauens abholen bzw. sich liefern lassen.

Die Wechselwilligkeit ist äußerst gering. In jeden Belangen. Man wechselt auch ungern den Telefonanbieter oder Stromanbieter. Es ist an sich keine große Hürde, man scheut aber die Risiken die das Ganze mit sich bringt. Der (urbane) Mensch an sich ist sehr bequem, was solche Dinge angeht.

Und das Framedoubling-Feature ist doch nur ein Notbehelf weil die Panel-Hersteller es immer noch nicht hinbekommen bessere Panels herzustellen. Und alles unter 23.xxx/ 25 fps ist doch eh völlig egal. Darunter will doch niemand irgendetwas konsumieren.
Allein die Tatsache, dass man uns 29"er mit 768p oder 34" mit 1080p andreht ist doch schon Zeugnis genug, was die Hersteller so von ihren Kunden halten.:freak:

Es krankt leider im ganzen (Monitor-)Körper und man möchte kein Geld für die Heilung ausgeben.

Dimitri Mayakovsky

2015-04-13, 13:16:17

gnomi

2015-04-13, 13:17:17

Warum genau? Weil sie 100EUR mehr bezahlen wollen für ein proprietäres NV-Feature das man genau so über den DP-Standard bekommen kann? Dann sollen sie doch, aber dann bitte nachher nicht jammern. Ja NV war um ein paar Monate früher dran und ja AMD sollte noch das Framedoubeling implementieren, aber das wars dann auch schon. Grundsätzlich funktioniert FreeSync um nichts schlechter, entgegen mancher Horrorgeschichten von wegen das syncen geht nicht ohne Modul. Der AMD-Ansatz wäre IMO gerade für den Kunden die sinnvollere Alternative.

Die beiden Gründe reichen doch. :confused:
Viele machen auch nicht so wie ihr hier eine riesen Sache draus.
Da wird das in den eigenen Augen beste zum gewünschten Zeitpunkt gekauft und fertig.
Und Vergleiche um jeden Euro per Geizhals macht auch in diesem Segment sicherlich nicht jeder, sondern es wird dort bestellt, wo die eigenen Erfahrungen eben entsprechend gut waren.
Ich finde das alles auch wesentlich vernünftiger und praktischer, als zu theoretisieren oder gar zu vermuten, dass uns nvidia nur mit ihrer proprietären Technolgie mit dem Modul bescheisst und knebelt.
Das ganze ist selbst mit dem Hintergrund der 970 in einer Zeit maßloser Werbeversprechen doch Kleinkram.
Im schlimmsten Fall muss ich den GSync Monitor eben noch etwas behalten und die nächste nvidia Karte ist etwas langsamer.
Selbst dieser Worst Case stört mich zunächst mal kein Stück.
Bei Intel brauche ich ja auch immer das passende Mainbord und kann nicht mehr einfach auf AMD oder eine andere CPU wechseln.

Tesseract

2015-04-13, 13:22:02

Der wie beschriebene starre Vorgang ist statisch, da Triple Buffering immer den ältesten Buffer nutzt, so auch ein neuerer zur Verfügung steht. Genau dies tut G-Sync nicht und ist auch kein Ringbuffer.
tut es nicht. render ahead nutzt immer den ältesten buffer aus dem ring, triple buffer immer den neuesten fertigen backbuffer. genau das ist der unterschied zwischen den beiden varianten.

fondness

2015-04-13, 13:22:35

Was ist, wenn es FrameDoubling bei AMD nicht gibt, niemals geben wird? Dann sind die 100€ bei einem 500€+ Monitor sehr gut angelegtes Geld.

Selbst wenn es so wäre gilt das nur so lange, wie es keinen Monitor gibt der bis sagen wir mal 20-25Hz runtern syncen kann, denn dann wäre das Framedoubeling überflüssig. Und selbst wenn nicht spielt nicht jeder mit so niedrigen fps dass das in der Praxis überhaupt relevant ist.

Dimitri Mayakovsky

2015-04-13, 13:26:19

tut es nicht. render ahead nutzt immer den ältesten buffer aus dem ring, triple buffer immer den neuesten fertigen backbuffer. genau das ist der unterschied zwischen den beiden varianten.
Es geht um den (relativ seltenen) Fall einer Kollision zw. fertigem Rendern und V-Swap.

Selbst wenn es so wäre gilt das nur so lange, wie es keinen Monitor gibt der bis sagen wir mal 20-25Hz runtern syncen kann, denn dann wäre das Framedoubeling überflüssig. Und selbst wenn nicht spielt nicht jeder mit so niedrigen fps dass das in der Praxis überhaupt relevant ist.
Es gibt heute aber keinen Monitor, der bis 20Hz runter kann.

Und nein, dieses FrameDoubling ist mitnichten irrelevant, was für ein Quatsch.

Troyan

2015-04-13, 13:26:41

Das bei Freesync kein Overdrive funktioniert, wird dabei einfach ignoriert. Das alleine rechtfertigt schon den Aufpreis.

Die Preise in Deutschland sind kaum unterschiedlich. BenQ und der Swift kosten annährend gleich viel.
Ein 24" 1080p 6bit TN Panel mit G-Sync ist 100€ günstiger als ein 27" 1440p 6bit TN Panel mit Freesync.

Schaffe89

2015-04-13, 13:36:46

Das kann ich dich schon lange nicht mehr.

Spätestens seitdem du dir zurecht gelogen hast, ich hätte keinen Unterschied G-Sync/A-Sync benannt. Ich mache seit Tagen nichts Anderes.

Sry, aber wenn du den Beitrag genauer gelesen hättest, dann würde dir auffallen, dass eine Dinge die du Gipsel an den Kopf wirfst gar nicht in der Form gesagt wurden.:wink:

Es ist trotzdem falsch und widerspricht auch dem, was deine eigenen Quellen sagen. TripleBuffering ist einfach der falsche Fachterm. Punkt.

Es funktioniert trotzdem wie klassisches TRipple Buffering und das Aufhängen an einem Fachterm hat ja nun wirklich keine besondere Substanz.
Letztendlich leuchtet es ein, wieso AMD dies auch mit dem Treiber umsetzen kann.

Du willst mit aller Macht dass G-sync unerreicht bleibt, das ist das Problem an der Geschichte.

Solange uns AMD keine FreeSync-Implementierung zeigt, die ein FrameDoubling ala G-Sync durchführt, ist es leider nur eine unbewiesen Behauptung von dir.

Die Argumentation war eher, dass es prinzipiell möglich ist und nicht die, dass Freesync das beherscht.
Ich kann mir keinen Reim darauf machen wieso Nvidia dieses Modul wirklich benötigt.

Gipsel

2015-04-13, 13:40:28

tut es nicht. render ahead nutzt immer den ältesten buffer aus dem ring, triple buffer immer den neuesten fertigen backbuffer. genau das ist der unterschied zwischen den beiden varianten.Und selbst ohne Überspringen von Frames (also einer Framequeue) wird das eigentlich nur wichtig, wenn die Frametimes kürzer als die Refreshdauern werden können. Ansonsten hat man bei einer Framerate unterhalb der maximalen Refreshrate kein zusätzliches Frame, was noch irgendwo rumliegt. Man bleibt ja bei einem Refresh nicht krampfhaft bei einem alten Frame, wenn schon ein neues fertig ist, nur weil ein drittes noch nicht fertig ist. Dieser zusätzliche Frame Latenz tritt also nur bei fps>=Refreshrate auf. Da hilft dann das Überspringen (Verringerung der Latenz, dafür etwas Judder).
Die manchmal zu beobachtenden Eingabelags kommen von einem (zu) hohen Prerenderlimit wenn die GPU limitiert, so daß die CPU z.B. schon die Drawcalls für das übernächste Frame queued (und damit keine Eingaben mehr dafür berücksichtigt werden können), obwohl die GPU gerade mal mit dem aktuellen Frame fertig geworden ist. Daß ist ein Problem der Engine (bzw. wie die das handhabt), was erstmal nicht direkt was mit der Anzahl der Framebuffer zu tun hat. Das ist ein häufiges Mißverständnis.

Unicous

2015-04-13, 13:45:20

@Troyan

Wie oft eigentlich noch. Overdrive und andere Features haben nichts mit Adaptive Sync/FreeSync zu tun.

Offensichtlich haben die Hersteller Probleme es ordentlich zu implementieren, aber Adaptive Sync schließt andere Features nicht automatisch aus.

Zum BenQ vs ROG Swift. Wie oft muss man eigentlich noch sagen, dass der ROG Swift ein exklusives Panel hat, das nicht mal in den Datenbanken wie z.B. panellook auftauchen.

https://twitter.com/TFTCentral/status/575701197010649088

Confirmation that the BenQ XL2730Z is using an AU Optronics M270DTN01.0 TN Film panel. Different to the Asus ROG Swift PG278Q (M270Q002 V0)

Dein Vergleich hinkt also gewaltig. Der ROG Swift ist übrigens in den USA preisstabil und kostet genau 150 Dollar mehr als der BenQ. In Deutschland ist der Preis Lädenübergreifend um ca. 20 Euro am 20.03 gefallen, einen Tag nach FreeSync Launch. Davor gab es nur wenige Läden die ihn für knapp 700 Euro verkauft haben. Der BenQ sollte wohl ursprünglich auch eine UVP 599 Euro und nicht 699 Euro haben. Auch das kann man u.a. bei gh sehen.

Gipsel

2015-04-13, 13:46:48

Es funktioniert trotzdem wie klassisches TRipple Buffering und das Aufhängen an einem Fachterm hat ja nun wirklich keine besondere Substanz.Zumal es auch absolut lächerlich ist. Jeder, der davon nur ein wenig Ahnung hat, wird bestätigen, daß das Verhalten Triple Buffering entspricht. Er hängt sich doch im Prinzip nur daran auf, daß bei Wikipedia(!) steht, daß die Buffer im "Video-RAM der Grafikkarte" liegen. Was ist, wenn man gar keine Grafikkarte sondern eine APU hat? :freak:
Es ist für die Funktionalität schlicht egal, wo genau die Puffer liegen, entscheidend ist, wie sie arbeiten.

Troyan

2015-04-13, 13:59:13

@Troyan

Wie oft eigentlich noch. Overdrive und andere Features haben nichts mit Adaptive Sync/FreeSync zu tun.

Offensichtlich haben die Hersteller Probleme es ordentlich zu implementieren, aber Adaptive Sync schließt andere Features nicht automatisch aus.

Die veröffentlichen Monitore haben dieses Problem. Damit ist eine Diskussion über Preisunterschiede nicht vernünftig möglich.

Zum BenQ vs ROG Swift. Wie oft muss man eigentlich noch sagen, dass der ROG Swift ein exklusives Panel hat, das nicht mal in den Datenbanken wie z.B. panellook auftauchen.

https://twitter.com/TFTCentral/status/575701197010649088

Dein Vergleich hinkt also gewaltig. Der ROG Swift ist übrigens in den USA preisstabil und kostet genau 150 Dollar mehr als der BenQ. In Deutschland ist der Preis Lädenübergreifend um ca. 20 Euro am 20.03 gefallen, einen Tag nach FreeSync Launch. Davor gab es nur wenige Läden die ihn für knapp 700 Euro verkauft haben. Der BenQ sollte wohl ursprünglich auch eine UVP 599 Euro und nicht 699 Euro haben. Auch das kann man u.a. bei gh sehen.

Der Acer 4K Monitor kostet in den USA $899, bei uns nicht mal 600€.
Der BenQ und der Swift haben beide gleiche Spezifikationen. Auch die Testergebnisse sind fast identisch: http://pclab.pl/art62998.html

Preislich sind es 30€ zwischen dem BenQ und dem Swift.

nalye

2015-04-13, 14:10:01

Aufgeräumt, Punkte vergeben und hier ist jetzt wieder Frieden und Ruhe drin, sonst fährt der Kartenzug munter weiter

Tesseract

2015-04-13, 14:19:36

dass doppelte frames aus sicht des protokolls bzw. der monitore möglich sind ist offensichtlich. warum es die GPU momentan nicht macht müsste man AMD fragen - aber selbst wenn es irgendeinen grund geben sollte warum die GPU das nicht kann (was ich für sehr unwahrscheinlich halte), ließe sich das mit neuen GPUs ändern ohne am protokoll oder den monitoren was ändern zu müssen.
wenn ich raten müsste würde ich sagen die softwareabteilung von AMD ist momentan einfach vollkommen überfordert bzw. unterbesetzt und kommt mit dem implementieren nicht nach weil andere dinge (z.B. GTA5) priorität haben.

krötenfresse

2015-04-13, 17:47:06

Es gibt heute aber keinen Monitor, der bis 20Hz runter kann.

das interessiert mich an dieser stelle mal....stimmt das?

die werbung sagt doch, dass selbst niedrige frameraten mit a-sync noch flott aussehen.
würde ja dann nicht stimmen.

Screemer

2015-04-13, 17:53:33

Die panels gehen bei FS derzeit nur bis 40/48hz. Gsync waren 36 wenn ich mich recht erinnere. Flüssiger wird durch framedoubling. 20fps auf 40fps aufgepumpt sind aber trotz dem zäh.

Deinorius

2015-04-13, 17:56:56

Allein die Tatsache, dass man uns 29"er mit 768p oder 34" mit 1080p andreht ist doch schon Zeugnis genug, was die Hersteller so von ihren Kunden halten.:freak:

Wo gibt es diese 768p Monitore? Gelistet scheinen die in Europa nicht zu sein.

http://geizhals.at/?cat=monlcd19wide&asuch=&bpmax=&v=e&hloc=at&hloc=de&hloc=pl&hloc=uk&plz=&dist=&sort=t&xf=952_21%3A9

1080p bei 34"/21:9 finde ich zumindest als günstigere Version überhaupt nicht schlimm. Das entspricht bei 16:9 einer Höhe, die 27" Monitoren entspricht. Sicher, viele haben bei der Größe lieber die höhere Auflösung, aber auch nicht alle. Die Regel sollte es aber auch nicht werden. ;)

Gipsel

2015-04-13, 18:17:12

Die panels gehen bei FS derzeit nur bis 40/48hz. Gsync waren 36 wenn ich mich recht erinnere. Flüssiger wird durch framedoubling. 20fps auf 40fps aufgepumpt sind aber trotz dem zäh.An den fps selber ändert sich ja nichts. Das Framedoubling ermöglicht nur, daß ein neues Frame dann auch wieder sofort dargestellt werden kann und das nicht zusätzlich unnötig verzögert wird, wie das bei FreeSync momentan der Fall zu sein scheint (warum auch immer), was den Lag erhöht und Judder verursacht.

Screemer

2015-04-13, 18:26:39

Wollte ich auch nicht damit ausdrücken. Weniger als 30-40fps als input sind für mich eh zu wenig. Da kann ich grad mal civ oä spielen. Zäh ist einfach zäh. Ob mit tearing oder ohne ist mir da auch wurscht.

myMind

2015-04-13, 18:55:48

Es funktioniert trotzdem wie klassisches TRipple Buffering ...
Ist mir ein totales Rätsel, wie man das immer wieder behaupten kann, obwohl die bekannten Nachteile von Tripple Buffering gar nicht auftreten. Das ist offensichtlich nicht plausibel.

Dimitris Art und Weise wie er argumentiert ist schon sehr grenzwertig, aber in der Sache liegt er meiner Meinung nach richtig. G-Sync funktioniert einfach anders. Wie genau weiß hier niemand. Ich würde eher spekulieren, dass die Grafikkarte die gerenderten Frames kontinuierlich wegsenden kann und diese ebenso kontinuierlich im RAM des G-Sync-Moduls abgelegt werden (Ringpuffer). Der Algorithmus im Monitor kann dann geschickt entscheiden, welchen Speicherzeiger er zum Panel sendet. Wichtige Nebenaufgabe: Sinnvolles Nachführen der Panelfrequenz, damit der Puffer möglichst immer leer läuft.

Für eine Frameverdoppelung muss wahrscheinlich auch nichts umkopiert werden, sondern es wird einfach nochmal auf das bereits vorhandene Bild verwiesen, wenn kein neues da ist.

Das ist natürlich auch nur geraten, liegt aber mit Sicherheit näher an der Wahrheit als Triple Buffering. Es ist nicht erklärlich, wozu man fast 1GB Speicher verbaut, wenn man nur ein Bild zwischenspeichern will.

dargo

2015-04-13, 19:02:22

Es ist nicht erklärlich, wozu man fast 1GB Speicher verbaut, wenn man nur ein Bild zwischenspeichern will.
Einer hatte mal die Bandbreite in den Raum geworfen. Was ist davon zu halten?

Edit:
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.
http://www.anandtech.com/show/7582/nvidia-gsync-review

Gipsel

2015-04-13, 19:14:12

Ist mir ein totales Rätsel, wie man das immer wieder behaupten kann, obwohl die bekannten Nachteile von Tripple Buffering gar nicht auftreten. Das ist offensichtlich nicht plausibel.Welche Nachteile von Triple Buffering? Ansonsten z.B. auch hier noch mal schauen (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=10587938#post10587938).

Oder um eine klare Aussage zu treffen, die Kombination mit dem dynamischen Refresh von A-/G-Sync beseitigt gerade die potentiellen Nachteile wie die erhöhte Judderneigung, erhält aber den Vorteil der höheren Performance. Letzterer Punkt spielt aber nur eine Rolle, wenn ein neues Frame fertig wird, während ein altes gerade zum Refresh des Displays benutzt wird. Dies sollte bei cleverer Handhabung der Zwangsrefreshes bei niedrigen Frameraten ("Framedoubling") aber eigentlich recht selten zum Tragen kommen. Insofern kann man sich auch auf den Standpunkt stellen, daß man es eigentlich nicht wirklich benötigt. Dazu kommt, daß gar nicht klar ist, ob nV das wirklich nutzt (es war der erfolglose Versuch ein Szenario zu konstruieren, wo man das GSync-Modul unbedingt braucht). Sie könnten es tun.

G-Sync funktioniert einfach anders. Wie genau weiß hier niemand. Ich würde eher spekulieren, dass die Grafikkarte die gerenderten Frames kontinuierlich wegsenden kann und diese ebenso kontinuierlich im RAM des G-Sync-Moduls abgelegt werden (Ringpuffer). Der Algorithmus im Monitor kann dann geschickt entscheiden, welchen Speicherzeiger er zum Panel sendet. Wichtige Nebenaufgabe: Sinnvolles Nachführen der Panelfrequenz, damit der Puffer möglichst immer leer läuft.Kannst Du mal erläutern, was da anders laufen würde, als auf einer GPU? Bei einem Bufferflip auf der GPU wird auch nur der Zeiger auf den aktuell ausgelesenen Framebuffer geändert.
Und die "geschickte" Entscheidung, welches Frame man anzeigt, ist doch wohl recht einfach: einfach das neueste. Oder gibt es Fälle, wo das nicht so ist?
Bei vielen Sachen muß man nicht groß drumrum wundern, die sind eigentlich ziemlich einfach. ;)
Für eine Frameverdoppelung muss wahrscheinlich auch nichts umkopiert werden, sondern es wird einfach nochmal auf das bereits vorhandene Bild verwiesen, wenn kein neues da ist.Also genau das, was man schon immer auf der GPU auch macht, wenn die Refreshrate höher als die Framerate ist: Es wird einfach das gleiche Frame nochmal dargestellt. ;)
Wo man optimieren kann, ist daß man z.B. nicht die Maximaldauer wartet, sondern bei niedrigen Frameraten schon nach der halben Frametime des vorherigen Frames einen Refresh anstößt, so daß es unwahrscheinlicher wird, daß die Fertigstellung eines neuen Frames mit der wiederholten Übertragung des alten Frames kollidiert, das neue Frame also warten muß, bis es zur Anzeige kommt.
Das ist natürlich auch nur geraten, liegt aber mit Sicherheit näher an der Wahrheit als Triple Buffering. Es ist nicht erklärlich, wozu man fast 1GB Speicher verbaut, wenn man nur ein Bild zwischenspeichern will.Doch, kleinere Speicherchips als 256MB gab es praktisch nicht mehr und man benötigte drei, um auf die Bandbreite zu kommen, die nV vorschwebte. Es ist in gewissem Sinne Verschwendung, so viel benötigt man nicht. Aber es war vermutlich die billigste Variante.

dargo

2015-04-13, 19:41:10

Ist das eigentlich eine 32Bit Anbindung je Speicherchip?

Gipsel

2015-04-13, 19:49:49

Ist das eigentlich eine 32Bit Anbindung je Speicherchip?Nein, nur 16Bit. Aber es sind die am breitesten angebundenen DDR3-Chips, die Hynix anbietet (haben sonst noch 8Bit und 4Bit pro Chip) (https://www.skhynix.com/products/computing/computing.jsp?info.ramCategory=computing&info.ramKind=19&info.eol=NOT&posMap=computingDDR3).

dargo

2015-04-13, 19:52:01

Autsch. Ok, noch ein Grund mehr für die 3 Chips.

myMind

2015-04-14, 03:02:12

Welche Nachteile von Triple Buffering? Ansonsten z.B. auch hier noch mal schauen (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=10587938#post10587938).

Oder um eine klare Aussage zu treffen, die Kombination mit dem dynamischen Refresh von A-/G-Sync beseitigt gerade die potentiellen Nachteile wie die erhöhte Judderneigung, erhält aber den Vorteil der höheren Performance. Letzterer Punkt spielt aber nur eine Rolle, wenn ein neues Frame fertig wird, während ein altes gerade zum Refresh des Displays benutzt wird. Dies sollte bei cleverer Handhabung der Zwangsrefreshes bei niedrigen Frameraten ("Framedoubling") aber eigentlich recht selten zum Tragen kommen. Insofern kann man sich auch auf den Standpunkt stellen, daß man es eigentlich nicht wirklich benötigt. Dazu kommt, daß gar nicht klar ist, ob nV das wirklich nutzt (es war der erfolglose Versuch ein Szenario zu konstruieren, wo man das GSync-Modul unbedingt braucht). Sie könnten es tun.

Aus der Argumentation werde ich nicht wirklich schlau. Kannst Du mal versuchen klarer auszudrücken, was du meinst. Irgendwie sagst Du A-/G-Sync behebt die nachteiligen Eigenschaften von Tripple Buffering, willst es dann - aus einer mir unbekannten Motivation heraus - weiterhin Tripple Buffering nennen. Und das obwohl gar nicht genau bekannt ist, auf welche Art und Weise die Verbesserung stattfindet. Das ergibt für mich überhaupt keinen Sinn.
Kannst Du mal erläutern, was da anders laufen würde, als auf einer GPU? Bei einem Bufferflip auf der GPU wird auch nur der Zeiger auf den aktuell ausgelesenen Framebuffer geändert.
Kann sein, dass das alles auf der GPU auch in der Qualität möglich sein wird. Will ich gar nicht ausschließen.

Und die "geschickte" Entscheidung, welches Frame man anzeigt, ist doch wohl recht einfach: einfach das neueste. Oder gibt es Fälle, wo das nicht so ist?
Aus meiner Sicht stehen die Anforderungen "keine Verzögerung" und "flüssiger Ablauf" unter bestimmten Umständen durchaus im Wiederspruch zueinander. Beispiel zur Verdeutlichung: Stell dir vor du führst eine 360° Drehung in 1 Sekunde durch. Die Berechnung eines Bildes benötigt 1 Sekunde. Jetzt gibt es die Möglichkeit genau das letzte Bild zu berechnen oder man lässt sich Zeit, berechnet 3 Zwischenbilder und gibt die Bewegung innnerhalb von 4 Sekunden aus. Das eine ist lagfrei, aber man sieht die Bewegung gar nicht, das andere wirkt verzögert, laggy, aber flüssig.
Dies nur als Beispiel, das eine "geschickte" Wahl nicht immer glasklar sein muss. Ich glaube nicht, dass es so einfach ist, wie wir uns das hier zusammenreimen.

Bei vielen Sachen muß man nicht groß drumrum wundern, die sind eigentlich ziemlich einfach. ;)
Also genau das, was man schon immer auf der GPU auch macht, wenn die Refreshrate höher als die Framerate ist: Es wird einfach das gleiche Frame nochmal dargestellt. ;)
Wo man optimieren kann, ist daß man z.B. nicht die Maximaldauer wartet, sondern bei niedrigen Frameraten schon nach der halben Frametime des vorherigen Frames einen Refresh anstößt, so daß es unwahrscheinlicher wird, daß die Fertigstellung eines neuen Frames mit der wiederholten Übertragung des alten Frames kollidiert, das neue Frame also warten muß, bis es zur Anzeige kommt.
Doch, kleinere Speicherchips als 256MB gab es praktisch nicht mehr und man benötigte drei, um auf die Bandbreite zu kommen, die nV vorschwebte. Es ist in gewissem Sinne Verschwendung, so viel benötigt man nicht. Aber es war vermutlich die billigste Variante.
Daraus kann man nicht schließen, das der Speicher für die von nVidia implementiere Logik nicht notwendig ist. Ich will nicht behaupten, dass zwingend soviel Speicher notwendig ist, um auf eine gleichwertige Lösung zu kommen. Umgekehrt kann es aber auch sein, dass man ohne zusätzlichen Speicher oder ohne weitere Zusatzhardware, an einer gleichwertigen Lösung scheitert, so wie es aktuell der Fall ist.

Gipsel

2015-04-14, 04:54:41

Aus der Argumentation werde ich nicht wirklich schlau. Kannst Du mal versuchen klarer auszudrücken, was du meinst. Irgendwie sagst Du A-/G-Sync behebt die nachteiligen Eigenschaften von Tripple Buffering, willst es dann - aus einer mir unbekannten Motivation heraus - weiterhin Tripple Buffering nennen.Weil triple Buffering triple Buffering bleibt, egal ob man das im Zusammenspiel mit A-/GSync betreibt oder nicht.
A-/GSync funktionieren erstmal unabhängig davon, ob man double oder triple buffering macht. Aber wenn man es zusammen benutzen würde, ergeben sich eben Auswirkungen auf das Verhalten im Zusammenspiel.

Man kann A-Sync und G-Sync mit ganz normalem double buffering betreiben. Führt das G-Sync-Modul gerade einen Zwangs-/Zwischenrefresh aus dem Speicher des GSync-Moduls aus und wird gleichzeitig ein neues Frame fertig, wartet die GPU, bis es an das Modul geschickt wird, in dieser Wartezeit kann die GPU nicht mit der Berechnung des nächsten Frames anfangen. So weit, so unspannend.
NVidia könnte in diesem Fall aber auch das Frame trotzdem senden. Es wird dann nicht direkt für den Bildaufbau benutzt (da dafür erst der Refresh des Panels mit dem älteren Frame aus dem Speicher des GSync-Moduls abgeschlossen werden muß, damit es kein Tearing gibt), sondern in einem zusätzlichen Puffer im GSync-Modul abgelegt. Dadurch wird ein Puffer im VRAM frei (der mit dem gerade fertig gewordenen Frame wird zurm GSync-Modul kopiert, der andere kann dann für das Rendern des nächsten Frames benutzt werden) und die GPU kann die Arbeit ohne Unterbrechung fortsetzen. Das ist dann genau Triple Buffering (mit dem dritten Puffer [der gerade angezeigt wird] auf dem GSync-Modul). Exakt den gleichen Effekt erreicht man, wenn man das auf der GPU-Seite aktiviert. Nur wenn es eine Kollision mit einem laufenden Refresh aus dem Puffer zur Anzeige auf dem Bildschirm gibt, wird der dritte Puffer genutzt, ansonsten wird immer sofort der gerade fertiggestellte Frame zum Display gesendet. Das funktioniert, weil die Frameausgabe eben mit der Fertigstellung der Frames synchronisiert wird (anders als bei festen Refreshraten). Es ist also ein Effekt der Kombination mit dem dynamischen Refresh. Dadurch bleibt es aber trotzdem triple buffering, weil es prinzipiell eben zwei Backbuffer und einen Frontbuffer gibt. Der zweite Backbuffer wird aber eben nur bei den beschriebenen Kollisionen benutzt. Die kommen bei festen Refreshraten praktisch immer vor (weil die Synchronisation zwischen dem Rendern der Frames und der Anzeige fehlt), bei dynamischen Refreshraten dagegen recht selten (insbesondere wenn man sich beim Framedoubling clever anstellt).

Ergibt das jetzt mehr Sinn?
Aus meiner Sicht stehen die Anforderungen "keine Verzögerung" und "flüssiger Ablauf" unter bestimmten Umständen durchaus im Wiederspruch zueinander. Beispiel zur Verdeutlichung: Stell dir vor du führst eine 360° Drehung in 1 Sekunde durch. Die Berechnung eines Bildes benötigt 1 Sekunde. Jetzt gibt es die Möglichkeit genau das letzte Bild zu berechnen oder man lässt sich Zeit, berechnet 3 Zwischenbilder und gibt die Bewegung innnerhalb von 4 Sekunden aus. Das eine ist lagfrei, aber man sieht die Bewegung gar nicht, das andere wirkt verzögert, laggy, aber flüssig.
Dies nur als Beispiel, das eine "geschickte" Wahl nicht immer glasklar sein muss. Ich glaube nicht, dass es so einfach ist, wie wir uns das hier zusammenreimen.Darauf haben A-/GSync aber überhaupt keinen Einfluß. Welche Bilder gerendert werden, entscheidet die Engine. A-/GSync befassen sich nur mit der synchronisierten Darstellung der gerenderten Bilder. Die müssen also mit dem arbeiten, was die GPU ausspuckt. Sie versuchen nur, berechnete Bilder möglichst sofort auszugeben und eben nicht die nächste Refreshperiode abzuwarten, die im Zweifelsfall erst 16ms später beginnt. Dafür wird genutzt, daß LCD-Panels auch etwas langsamer refreshed werden können. Durch Dehnung des Abstands zwischen den Refreshes (bei Frameraten unter der maximalen Refreshrate), kann bei einem neuen Frame direkt mit der Darstellung des neuen Frames angefangen werden, weil eben gerade kein Refresh läuft, der noch abgeschlossen werden müßte, bevor man mit dem nächsten anfängt (keine Kollision zwischen neuem Frame und laufendem Refresh!). Das ist im Prinzip schon Alles.
Also doch, es ist so einfach ;).