Blur Busters Forums

Who you gonna call? The Blur Busters! For Everything Better Than 60Hz™ Skip to content

Blur Buster's G-SYNC 101 Series Discussion

Talk about NVIDIA G-SYNC, a variable refresh rate (VRR) technology. G-SYNC eliminates stutters, tearing, and reduces input lag. List of G-SYNC Monitors.

Re: Blur Buster's G-SYNC 101 Series Discussion

Postby Chief Blur Buster » 05 Jun 2018, 10:30

Advanced Reading for Advanced Users

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.

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)

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).

KKNDT wrote:I have questions about the VBI:

Before I answer, I need to explain to readers about the purpose of VBI. (Ever wonder where "VSYNC" comes from?)

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:
KKNDT wrote:1. Default VBI consists of VBPD, VFPD, VSPW. Which one is to be changed during VRR opertation?

Disambiguation for readers:
VBPD = "Vertical Back Porch" seen in ToastyX CRU
VFPD = "Vertical Front Porch" seen in ToastyX CRU
VSPW = "Vertical Sync" interval seen in ToastyX CRU

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?

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.

(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).

Head of Blur Busters - | | Follow @BlurBusters on Twitter!
To support Blur Busters: Official List of Best Gaming Monitors | G-SYNC | FreeSync | Ultrawide
User avatar
Chief Blur Buster
Site Admin
Posts: 4791
Joined: 05 Dec 2013, 15:44

Re: Blur Buster's G-SYNC 101 Series Discussion

Postby KKNDT » 09 Jun 2018, 03:05

That's very TECHNICAL!

So I guess the story of pixels transmitting from the graphics card to the monitor via the cable is like this


If you use resolution lower than native without scaling, the black area surounds the active is just the porch?
1.png (9.97 KiB) Viewed 151 times
Posts: 42
Joined: 01 Jan 2018, 08:56

Re: Blur Buster's G-SYNC 101 Series Discussion

Postby Chief Blur Buster » 10 Jun 2018, 03:54

Pretty close, topologically.

It's an infinite repeating sequence (Sync-FrontPorch-Active-BackPorch-Sync-FrontPorch-Active-BackPorch-Sync-FrontPorch-Active-BackPorch-etc-etc-etc) ... I usually think of it in this order: Sync-FrontPorch-Active-BackPorch even if from a VRR perspective it is sometimes more easily diagrammed as Active-BackPorch-Sync-FrontPorch like your diagram. But the infinite repeating sequence is still the same. [...]-Active-BackPorch-Sync-FrontPorch-Active-BackPorch-Sync-FrontPorch-Active-BackPorch-Sync-FrontPorch-[...] looping in that order every refresh cycle. With the Vertical Back Porch being used to time-pad between refresh cycles.

The horizontals are full height. Be noted that the vertical porches will often still have the horizontals embedded in them. Only the vertical sync is completely absent of the horizontal sync signal (in the analog era). Porches can essentially behave as extra virtual resolution and data has sometimes been hidden in them (e.g. closed captioning signal - offscreen Scan Line #21 just above the top edge).

So your black left edge will extend the full height (except it'll be absent from the vertical sync). Because the overscan area (vertical porches) still have horizontals embedded in them too. So they are still stuck at horizontal scanrate granularity.

From a signal structure -- it's the same for higher and lower resolution. Most of the time, the monitor is responsible for deciding what to do with the resolution (centered or scaled). If the monitor is doing the windowboxing, of course.

But yes, in the analog era at least -- porches are black-colored. In NTSC signals, the porches are 7.5 IRE (7.5/100ths of the voltage between complete black and complete white). And Sync is 0 IRE (0/100ths of the voltage between complete black and complete white). That's my understanding. Digitally, the meanings are often quite different, with the confusion of HDTV sets having a toggle for 0-to-100 IRE versus HDTV 7.5-to-100 IRE -- creating a black level difference. In the digital era, it's wasted dynamic range so we often use full range signals in the digital era.

Things can be confusing between the porches and active when things are being underscanned... but on analog displays you saw the image data of the porches. And you often saw the structure with ghosted signals (e.g. two NTSC signals overlapping each other -- one distant station showing a ghost image) -- with that, sometimes you saw the actual structure of the porches and sync.
Head of Blur Busters - | | Follow @BlurBusters on Twitter!
To support Blur Busters: Official List of Best Gaming Monitors | G-SYNC | FreeSync | Ultrawide
User avatar
Chief Blur Buster
Site Admin
Posts: 4791
Joined: 05 Dec 2013, 15:44


Return to G-SYNC

Who is online

Users browsing this forum: No registered users and 1 guest