Advanced Reading for Advanced Users
This is true, G-SYNC is proprietary, so my answer will be based on FreeSync / Adaptive-Sync / HDMI VRR behavior which all behave exactly the same at the blanking interval behaviour level (Timings & Resolution)jorimt wrote:Beyond the conceptual basics that I've already covered in my series, short of reverse engineering the G-SYNC module and G-SYNC driver component, I doubt we'll ever have the exact answer to such specific questions regarding G-SYNC inner workings, of which I'm sure Nvidia prefers; industry secrets and all that.
Portions will definitely also apply to G-SYNC because the panel is still the same (in both GSYNC and FreeSync) even if the monitor motherboard driving them is different. For example, the ViewSonic XG2530 FreeSync and XG2560 G-SYNC uses the same panel. Just different electronics driving the panel. At the end of the day, the panel is accepting synchronization signals, and so, the terminologies still kind of apply at the TCON level. Today, GSYNC is often (but not always) built into a custom TCON programmed by NVIDIA, so the answer may or may not apply at the LCD pixel level...
However, this will cover fundamental concepts of VRR since all transmissions over video cables still have synchronization signals (Porches, Sync, etc).
Before I answer, I need to explain to readers about the purpose of VBI. (Ever wonder where "VSYNC" comes from?)KKNDT wrote:I have questions about the VBI:
Even a 2018 DisplayPort cable is transmitting the same signal topology as a 1930s analog TV signal transmitting a calendar-style-sequence of imagery, top-to-bottom, left-to-right, involving 1930s era Porch signals and Sync signals, that are still used to this date regardless of cable format, and still applies to signals between an NVIDIA card and a GSYNC monitor. How the card and monitor handles them is up to question, but the method of serializing two-dimensions into one-dimensions remains unchanged for almost a century.
Whether year 1930s or 2020s, it's all the same:
- From left-to-right, is Horizontal Sync -> Horizontal Back Porch -> Horizontal Active -> Horizontal Front Porch
- From top-to-bottom, is Vertical Sync -> Vertical Back Porch -> Vertical Active -> Vertical Front Porch
- Sync signals in analog era controls a CRT gun to move to a new position (e.g. top edge, or left edge, or both)
- Sync signals in digital era is simply logic to tell electronics to "Prepare for a new row of pixels" or "Prepare for a new refresh cycle".
- Porches are simply overscan padding (safety padding between sync signal & active image).
- VRR simply commandeers the bottom edge overscan (Front Porch), varying it, to vary the timing of individual refresh cycles.
This is the way it has been done with serializing a 2D image over a one-dimensional wire or radio signal, and it has transferred over to digital and packetization standards, still in use digitally, even if the sync intervals are greatly reduced.
So, because the fundamental "serialization of 2D image into 1D wire" concepts remain unchanged for the better part of 100 years -- we can easily generalize how VRR was piggybacked onto this. While GSYNC is proprietary, it still has to adhere to a "cram 2D into 1D" concept, sticking to a reasonable amount of cable signal standardization (to be compatible with things like amplifiers, switches, etc), so a significant percentage of the answer will still apply to GSYNC even if extra proprietary data is embedded in the signal.
Here's my answer:
Disambiguation for readers:KKNDT wrote:1. Default VBI consists of VBPD, VFPD, VSPW. Which one is to be changed during VRR opertation?
VBPD = "Vertical Back Porch" seen in ToastyX CRU
VFPD = "Vertical Front Porch" seen in ToastyX CRU
VSPW = "Vertical Sync" interval seen in ToastyX CRU
Correct. During VRR operation, the monitor is held in continual transmission of Back Porch scanlines (VBPD) -- (metaphorically -- basically dummy rows of blank pixels hidden above the top edge of the screen). A variable Back Porch, while Sync and Front Porch remains fixed.KKNDT wrote:2. When buffer swap occurs, the game will trgger a new refresh cycle. Is it the VBPD who is leading the new cycle?
(For those who program Custom Resolutions and do FreeSync range overriding techniques: What gets entered in ToastyX CRU simply becomes the minimum-size Back Porch, and the FreeSync driver will automatically vary it to vary time between refresh cycles, down to the minimum Hz of the VRR range).
Interestingly, on this topic:
This adds an ultra-minor microseconds-league granularity behavior that few people know about:
During VRR, the timing of the next vertical refresh cycle is the granularity of the horizontal scanrate!
Once the buffer swap occurs (e.g. API call, Present() or glutSwapBuffers() occurs), the next scanline transmitted out of the graphics output will be the first row of pixels of the frame buffer (top edge of Active), right after the current still-scanning-out Back Porch scanline is complete. This cleverness allows adherance to classic video signal structure, while adding a VRR upgrade to it to allow display refresh cycles to be software-triggered.
NOTE1: If too much time passes without a buffer swap, the graphics card (at least on open VRR standards) will begin re-transmitting a duplicate of the previous refresh cycle. This is because pixels on a panel will go stale (e.g. fade away in a glitchy way) or go blank (e.g. go black or go white, due to electronics on the TCON) if too much time passes without a refresh cycle. So that's why you have a minimum Hz for a VRR.
NOTE2: For framerates below minimum Hz, there's a trick available. Low Frame Rate Compensation logic is simply intelligently timing the repeat-refresh cycles in a way to prevent colliding with the timing of API-triggered refresh cycles. So 24fps may actually cause the drivers to intelligently time the repeat refresh cycles exactly between API calls, creating a 48Hz out of 24fps (24 API calls per second). Done well, there's no stutter. However, random framerates (highly variable frametimes) can defeat this guessing logic of Low Frame Rate Compensation and timings of auto-repeat-refreshes will begin colliding with timings of software-API-triggered refresh cycles -- creating microstutter for framerates below minimum Hz of the VRR range.
If the display is currently scanning at ~160KHz horizontal scan rate (160,000 pixel rows per second including blanking interval), that means the new refresh cycle may be delayed by something like 1/160,000sec before it finally "hits the wire". That's because it waits for the current still-scanning out Back Porch scanline to finish, before beginning Pixel row #1 of the visible refresh cycle. There may be other driver and codec granularities being introduced (e.g. DisplayPort packetization) that adds a few scanlines of delay but practically, it's immediate.
Granularity in VRR operation that reaches the millisecond level, can become human-visible as ultra-minor microstutter, so it's critical that refresh timing remains in the <100us range. At 160KHz scanrate, that's less than 10 microseconds granularity between API call and the pixels hitting the cable -- far below a human's ability to detect.
VRR is piggybacked in such a clever way -- to point that FreeSync also unexpectedly successfully works on some analog MultiSync CRTs (at least the ones without oversensitive refresh-rate-change-blanking circuits, especially when refresh rate slewing isn't too quick).
</TECHNICAL REPLY>