Freesync: AMDs Konter zu G-Sync setzt auf offene Standards - erste Techdemo

[Superwip]

Die Schlussfolgerungen sind okay, aber die Ausgangstheorie, die du "aus dem Netz" hast, klingt arg abgehoben.
Mit VBLANK sendet man nicht "den Befehl, die Hz zu verlegen". (Und auch kein grammatikalisch verständliches Gegenstück zu diesem Gewurschtel)
VBLANK ist ein Befehl. Und zwar der Befehl an den Monitor: Du hast jetzt Zeit, von unten rechts nach oben links zu wechseln und dann darauf zu warten, dass der erste Pixel des neuen Bildes übertragen wird. Dementsprechend muss die Grafikkarte da keine nicht vorrausraten und es gibt keine Wiederholfrequenz, die übertragen werden müsste. Es ist, wie bereits erwähnt, eine asynchrone Übertragung, bei der es nichts zu synchronisieren gibt. Wenn die Grafikkarte nicht will, dass ein neues Bild angezeigt/das alte Wiederholt wird, dann sendet sie einfach fortwährend VBLANK und der Monitor wartet und wartet und wartet. Und diese Entscheidung kann die Grafikkarte jederzeit treffen und auch jederzeit wiederufen - ohne dass irgendwer irgendwelche latenzkritischen Berechnungen durchführen müsste.

Soweit jedenfalls die einzig mir bekannte Theorie, die so ganz nebenbei logisch und naheliegend ist und zu allem passt, was so über Monitoransteuerung erzählt wird.

Das ist nicht 100% richtig.
Auch wenn richtig ist das es keine Einschränkungen bei der Unterstützung Grafikkartenseitig geben sollte.

Im Falle von DVI hört die Grafikkarte nach dem Senden eines Frames einfach auf ein Bildsignal oder TMDS zu senden; wenn nichts neues gesendet wird bleibt das vorhandene Bild angezeigt, das neue Bild wird erst begonnen wenn wieder ein Signal kommt. Das "VBLANK"-Signal ist in dem Fall also einfach kein Signal. Während des Blankings ist es lediglich vorgesehen im TMDS kodierte HSYNC (optional) sowie den TMDS-Referenztakt weiter zu senden, das VSYNC Signal leitet dann (theoretisch irgendwann, das muss nicht nach einem festen Zeitintervall sein) die Darstellung eines neuen Bildes ein. Während des Blankings können auch die in TMDS kodierten CTL-Steuersignale welche aber kaum verwendet werden gesendet werden.

Im Falle von DP wird das Bildsignal nicht pixelweise per TMDS sondern in Datenpaketen gesendet. Diese besitzen einen Header in dem unter anderem der Wechsel zu einem neuen Bild gekennzeichnet ist. Ist der entsprechende Flag gesetzt bricht beginnt der Monitor ein neues Bild -egal ob das alte fertig ist-, werden keine neuen Daten übertragen bleibt das vorhandene Bild angezeigt. Hier ist von Grund auf keine Synchronisation -auch keine vertikale Synchronisation- vorgesehen und daher auch kein Wartesignal erforderlich. Der synchrone Betriebsmodus von DP wurde nachträglich auf den Standard aufgesetzt um einfache Kompatibilität zu Panels und Controllern zu wahren die aus welchen Gründen auch immer einen solchen erfordern.

Der asynchrone Betrieb liegt ja eigentlich auch in der Natur eines (egal ob LCD, LED oder OLED-) TFT Monitors, wenn man so will. Die Pixel speichern ihre Bildinformation und zeigen sie an bis sie refreshed werden egal wie lange das dauert (zumindest solange man ihnen nicht den Saft abdreht). Auch andere digitale Bildschirmtypen (Plasma, DLP, LCoS) sollten damit kein Problem haben; bei diesen Bildschirmtypen werden in der Regel Bilder als ganzes empfangen und vom Controller gespeichert welcher diese dann als ganzes ausgibt (beim Plasma erfolgt die Ausgabe prinzipiell auch pixelweise aber die mit vervielfachter Frequenz, vom Controller gesteuert). Auch hier ist es prinzipiell problemlos möglich eine variable Totzeit zwischen zwei Frames einzulegen. Lediglich CRTs erfordern eine konstante Bildwiederholrate mit einer Frequenz die in der Regel synchron zur Ausgabe der Grafikkarte ist.

___
Woran scheitert es denn dann überhaupt?

Anscheinend daran das bei machen (vielen, allen?) aktuellen Displaycontrollern einfach kein asynchroner Betrieb vorgesehen ist und daran das die Displays auch in nativer Auflösung oft nicht direkt sondern über einen Scaler angesteuert werden.