Hier gestern eine neue Veröfentlichung die sogar noch mehr Details direkt von AMD und Nvidia zur jeweiligen Technik klärt:
www.techreport.com/review/28073/benq-xl2730z-freesync-monitor-reviewed
Die ersten die darauf eingehen, was eigentlich passiert wenn beide Technologien ausserhalb der Panel-Frequenz operieren. Auf Seite 3 wird das Schritt für Schritt erklärt, doch es ist absolut lesenswert von Anfang an, um dann auf der Seite 3 folgen zu können.
Entscheidend für diese Diskussion ist ein Zitat von AMDs David Glen, einer der Freesync Entwickler:
I asked AMD's David Glen, one of the engineers behind FreeSync, about how AMD's variable-refresh scheme handles this same sort of low-FPS scenario. The basic behavior is similar to G-Sync's. If the wait for a new frame exceeds the display's tolerance, Glen said, "we show the frame again, and show it at the max rate the monitor supports." Once the screen has been painted, which presumably takes less than 6.94 ms on a 144Hz display, the monitor should be ready to accept a new frame at any time.
What FreeSync apparently lacks is G-Sync's added timing logic to avoid collisions. However, FreeSync is capable of operating with vsync disabled outside of the display's refresh range. In the event of a collision with a required refresh, Glen pointed out, FreeSync can optionally swap to a new frame in the middle of that refresh.
1. Fällt die Framerate unter die minimale Frequenz des Monitors, wird die Frequenz des Monitors auf Maximum erhöht und der selbe Frame wird ständig wiederholt
Wäre also geklärt was passiert. Nun also dazu wo das Bild her kommt, welches so lange wiederholt wird bis die GPU ein neues rendert. Würde es von der GPU kommen, wie das bei Double-Buffering passiert, würde das neue Bild gezeigt werden, nachdem das alte Bild ein zweites mal dargestellt wurde. Es wäre völlig unmöglich innerhalb der 6,94 ms bei 144Hz, die der Refresh benötigt um ein Bild darzustellen, diesen Vorgang zu unterbrechen und das in der Zwischenzeit fertig gerenderte Bild der GPU anzuzeigen, da dies ja erst geht wenn ein Buffer-Flip stattfindet und dann bei der nächsten Scanperiode das das neue Bild angezeigt wird.
Doch hier ist es anders wie der zweite farbige Satz zeigt:
2. Sollte es zu einer Kollision des neuen Bildes mit einem Refresh kommen, wird der Refresh unterbrochen und das neue Bild sofort dargestellt. Dies bedeutet es muss aus einem anderen Buffer kommen. Das Bild im Panel Self Refresh Buffer wird mit 144Hz wiederholt, das Bild aus der GPU kommt mit eine Framrate unter 40 FPS von der GPU, das bedeutet, dass das alte Bild mindestens 3-6 mal auf dem Panel dargestellt wurde (je nach Frametimes der einzelnen Frames unterhalb von 40 FPS)
Die GPU müsste also nicht nur einmal den Frame doppelt schicken, sondern bis zu 6 mal oder sogar öfter, als sie einen Frame rendern kann zu dem Zeitpunkt. Durch die Nutzung des Panel Self Refresh Buffers wird hier die Frequenz nicht nur verdoppelt, wie bei Nvidia, sondern maximiert, kann jedoch jedezeit unterbrochen werden durch den neuen Frame der GPU - eigentlich müsste hier Tearing entstehen in diesen Fällen (auf 144Hz Niveau), oder man aktiviert eben VSync wie es AMD anbietet, welches das abfängt und somit der Refreshframe zu Ende rendert und dann erst durch den neuen Frame der GPU nahltlos ersetzt wird ohne Tearing. Im Prinzip ein Triple-Buffering ohne Latenz-Penalty, da es keinen Buffer-Swap auf der GPU geben muss zwischen zwei Sekundär-Buffern um das neue Bild anzuzeigen. Es wird direkt angezeigt und unterbricht die PSR-Periode. Dies wäre nicht möglich wenn es keinen Bildschirm-basierenden Buffer geben würde der den Refresh unabhängig und abgekopelt durchführt.
Interessant auch die Details zum GSync Ansatz von Tom Peterson in dem Artikel:
Petersen explained that sorting out the timing of a variable-refresh scheme can be daunting when the wait for a new frame from the graphics card exceeds the display's maximum wait time. The obvious thing to do is to refresh the display again with a copy of the last frame. Trouble is, the very act of painting the screen takes some time, and it's quite possible the GPU have a new frame ready while the refresh is taking place. If that happens, you have a collision, with two frames contending for the same resource.
Nvidia has built some logic into its G-Sync control module that attempts to avoid such collisions. This logic uses a moving average of the past couple of GPU frame times in order to estimate what the current GPU frame-to-frame interval is likely to be. If the estimated interval is expected to exceed the display's max refresh time, the G-Sync module will preemptively refresh the display part way through the wait, rather than letting the LCD reach the point where it must be refreshed immediately.
This preemptive refresh "recharges" the LCD panel and extends its ability to wait for the next GPU frame. If the next frame arrives in about the same time as the last one, then this "early" refresh should pay off by preventing a collision between a new frame and a gotta-have-it-now refresh.
Die GPU nimmt den fließenden Durschnitt der letzten Frames und schätzt ab ob die Refreshzeit überschritten wird. Dann wird vorsorglich in doppelte Frequenzen geschaltet, bevor es eine Framekollision gibt. So soll ein neuer Frame immer eine Lücke bekommen in die er geschoben werden kann, bevor das Problem überhaupt entsteht. Eigentlich das selbe im Prinzip, nur das Nvidia hier etwas Feintunig gemacht hat um nicht die maximale Frequénz anlegen zu müssen. Schreibt ja auch der Tester dort. Sagen auch Tom Peterson von Nvidia und Tom Glen von AMD. Beide nutzen einen Panel-Buffer der sich selbst refresht um das umzusetzen.
