Pre-rendered frames etc. (continued from G-Sync 101 article)

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.
User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: Pre-rendered frames etc. (continued from G-Sync 101 arti

Post by Chief Blur Buster » 21 Jan 2019, 02:08

One caveat, if you use VRR -- forcing a large count of prerendered frames during GSYNC + VSYNC ON (in uncapped operation) might massively increase the sudden lag increase-decrease effect of slamming against VRR maximum of a display. e.g. For 144Hz FreeSync/GSYNC, hitting 144fps flat-out will pile-up the VSYNC ON framebuffer queue right up to the max prerendered frames. The lag differential during VRR operation (e.g. 30fps-144fps) and uncapped maxed-framerate operation (e.g. 144fps) would begin to become huge.

However, I envision this may be useful for VRR SLI improved framepacing operation, e.g. setting Prerendered to the count of GPUs that you have installed on your system. I have not tested this, however.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

User avatar
RealNC
Site Admin
Posts: 3737
Joined: 24 Dec 2013, 18:32
Contact:

Re: Pre-rendered frames etc. (continued from G-Sync 101 arti

Post by RealNC » 21 Jan 2019, 02:23

Chief Blur Buster wrote:One caveat, if you use VRR -- forcing a large count of prerendered frames during GSYNC + VSYNC ON (in uncapped operation) might massively increase the sudden lag increase-decrease effect of slamming against VRR maximum of a display.
This also happens when you can't reach the FPS cap due to GPU load. The higher you cap, the more often this will happen. This is why I set MPRF to 1 globally.

The backpressure of vsync has pretty much the same outcome as the backpressure of a GPU bottleneck. The CPU doesn't care either way, it will pile up input lag just the same.
SteamGitHubStack Overflow
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.

pegnose
Posts: 17
Joined: 29 Dec 2018, 04:22

Re: Pre-rendered frames etc. (continued from G-Sync 101 arti

Post by pegnose » 27 Jan 2019, 10:27

Chief Blur Buster wrote:Of all the requirements -- dynamic overdrive is the biggest difficulty.

It's horrendously complicated, especially in varying frametimes.

The overdrive needs to try to predict the next frametime, not the previous frametime, which is sometimes hard to guess. If you can't do dynamic overdrive properly -- an display engineer can easily get artifacts worse than fixed overdrive. To most people, it feels like voodoo science -- the art of overdrive tuning. Good dynamic overdrive required a powerful FPGA chip initially...
Could you perhaps spare a few words as to why dynamic overdrive tuning is a thing with VRR? Could you not just tune overdrive to the fastest frame transition needed on a given display with a set max G-Sync frame rate and leave it at that?

RealNC wrote:
Chief Blur Buster wrote:One caveat, if you use VRR -- forcing a large count of prerendered frames during GSYNC + VSYNC ON (in uncapped operation) might massively increase the sudden lag increase-decrease effect of slamming against VRR maximum of a display.
This also happens when you can't reach the FPS cap due to GPU load. The higher you cap, the more often this will happen. This is why I set MPRF to 1 globally.

The backpressure of vsync has pretty much the same outcome as the backpressure of a GPU bottleneck. The CPU doesn't care either way, it will pile up input lag just the same.
Makes sense. It does not matter why the CPU has some spare time if it is instructed to use it to produce more game data.

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: Pre-rendered frames etc. (continued from G-Sync 101 arti

Post by Chief Blur Buster » 27 Jan 2019, 22:54

<Blur Busters Technology Pandora Box>

Why VRR Displays (GSYNC, FreeSync) Need Dynamic Overdrive
pegnose wrote:Could you perhaps spare a few words as to why dynamic overdrive tuning is a thing with VRR? Could you not just tune overdrive to the fastest frame transition needed on a given display with a set max G-Sync frame rate and leave it at that?
That reduces motion quality especially if there's different overdrive needs at different refresh rates.

LCD pixels aren't static. Due to LCD being physical molecules that have momentum, there's a GtG pixel response (Grey to Grey). They're in continuous momentum (fades from one color to the next). Look at high speed videos of LCD Refresh Cycles

If you interrupt that momentum early or late, the average color of a pixel may be different. (photons emitted from that pixel for one frametime)

Now, when we intentionally change overdrive settings, you can see various ghosting artifacts:
  • Too excessive overdrive -- the trail is overshooting (bright corona)
  • Too little overdrive -- the trail is undershooting (big blurry trail)
  • Just right overdrive -- both the leading/trailing edges are symmetric motion blur.
Image

Imagine getting coronas at high framerate and ghosting at low framerates, only getting the neutral look at mid framerates. Now, the most common situation is that fixed overdrive is calibrated for the highest framerates in VRR, so what happens is that you get perfect looking motion at high Hz but you get coronas/ghosting a low framerates in VRR.

Now imagine that varying in realtime depending on framerate!
That's what happen on a very terrible poorly-tuned VRR display; the varying overshoot/undershoot behavior.

- Imagine a pixel still in transition during a variable frametime.
- We're transitioning from a darkgrey to lightgrey pixel.
- For simplicity, let's assume GtG100% for this particular color combo is one refresh cycle.
- Imagine 1st 33% of max-Hz refresh cycle, a particular specific pixel is dark-grey
- Imagine 2nd 33% of max-Hz refresh cycle, a particular specific pixel is mid-grey
- Imagine 3rd 33% of max-Hz refresh cycle, a particular specific pixel is light-grey
- Now, colormix 33% darkgrey, 33% grey, 33% lightgrey (temporal blend) = averages out to mid-grey pixel
- Now you shorten frametimes to only 80% of original
- You're temporally colormixing 33% darkgrey, 33% grey, and 13% lightgrey = averages out to a darker-grey pixel.
- Now the blurtrail looks different (ghostier or coronia-er)
- So thus... now you understand why we need dynamic overdrive for VRR!!!

(To monitor engineers: I know this is simplistic, but this is the easiest way to explain to laypersons not aware why variable overdrive is needed for variable refresh rate monitors).

You need dynamic overdrive to make sure that the average pixel color remains consistent, dynamically intelligently speeding up/slowing down pixel response to make sure that the pixel transitions look consistent with consistent motion blur at all frame rates (refresh rates).

And complicating things more, you need to predict the NEXT frametime to properly do dynamic overdrive, because the overdrive is to also help the upcoming refresh cycle that will replace the current (still GtG-momentuming) refresh cycle on the screen.

Now, complicating this EVEN more, is that GtG pixel response speed varies depending on the original color and final color. That means you may to tune over 65,000 different GtG combinations for each shade of grey (per color channel -- red, green, blue). So now you may have massive overdrive lookup tables that are also run with a variable formula that tries to predict the next frametime. Thus requiring a custom powerful FPGA chip in the TCON in the first G-SYNC monitors to do all that realtime per-pixel overdrive processing.... Now you know one of the (multiple) reasons why G-SYNC monitors tended to have a fairly big premium, for high quality variable overdrive, it's a massive amount of realtime processing to get the best quality dynamic overdrive!

To watch pixel response in realtime -- GtG in momentum -- look at the high speed videos of LCD refresh cycles. And you'll understand why a pixel is in continuous-changing-color, especially on slower LCDs. It's always fading from one color to the next (as the Liquid Crystal Display molecules in an LCD spin to block/unblock polarized light). The manufacturer rating of GtG is simply from the GtG 10% point in curve to GtG 90% point in curve. So a GtG benchmark for black-to-white transition is actually the the stopwatch time from a very dark-grey pixel to a very light-grey pixel. But the full GtG 100% is much longer, often over several refresh cycles on many screens. The artifacts of this can still remain human visible.

Faster native pixel response (e.g. 0.5ms overdriven GtG with 3ms native GtG) can lessen the need to do a dynamic overdrive. But dynamic overdrive makes motion consistency look better at a wider range of VRR framerates.

Oh, another pandora box item: Panel temperature! Like forgetting a smartphone in a freezing car in the middle of winter, and the screen responding sloooooow. Cold LCDs are really slow. Don't forget to warm up your panel to room temp if playing on a cold panel. Like when you're saving money and set the thermostat really low when away, then you start using the panel. So turn on the panel and run it for 30 mins to warm it up to reduce ghosting. Freezing rooms in cold may have more of a ghosty-variance effect for fluctuating VRR framerates. This is more problematic on VA panels but has also affected TN/IPS panels (e.g. more overdrive variance in VRR, or increased strobe crosstalk, or monitor ghosts/coronas a bit more than usual). You want to play the monitor at full room temperature (or slightly warmer) to match its original overdrive tuning for minimum ghosting/coronas.

</Blur Busters Technology Pandora Box>
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

MatrixQW
Posts: 278
Joined: 07 Jan 2019, 10:01

Re: Pre-rendered frames etc. (continued from G-Sync 101 arti

Post by MatrixQW » 01 Feb 2019, 11:58

I read all the information in this post.
One thing i never really got clear is if this setting works with v-sync off. But according to some tests, it does?
And from what i understand, it's function is not give more fps but to stabilize the game from suffering interruptions from small fps drops.
Also, it's not meant to be used as an input lag reducer but it's clear that with less buffering equals less input lag, so we can just say it reduces input lag with the value '1'.

Since r300 drivers it also works for opengl.
Last time i checked for opengl, if a game doesn't set a value, the NVCP 'let 3d app decide' would result in '2'. So in this case setting it to '1' would reduce buffering.

If a game sets '2' and NVCP '1', who overrides who?
Does the driver always controls the value or can a game override NVCP?

With g/v-sync 'off' and stable fps > hz, will that result in pre-rendered frames '0', or that only happens when stable fps < hz?

User avatar
jorimt
Posts: 2481
Joined: 04 Nov 2016, 10:44
Location: USA

Re: Pre-rendered frames etc. (continued from G-Sync 101 arti

Post by jorimt » 01 Feb 2019, 12:12

MatrixQW wrote:One thing i never really got clear is if this setting works with v-sync off.
I've never tested this directly, but my current understanding/strong assumption is, yes, pre-rendered frames are still in effect with V-SYNC off. Maybe someone else here can tell you for certain.
MatrixQW wrote:And from what i understand, it's function is not give more fps but to stabilize the game from suffering interruptions from small fps drops.
The whole subject is convoluted, to be sure, but "to give more fps (allow higher average framerate)" and to "stabilize the game from suffering interruptions from small fps drops (reduce frametime spikes)" are basically one in the same in this instance: pre-rendered frames tries to ensure there is always at least 1 next frame to present, which helps with both the above (connected) issues.
MatrixQW wrote:Also, it's not meant to be used as an input lag reducer but it's clear that with less buffering equals less input lag, so we can just say it reduces input lag with the value '1'.
In best case scenario, yes.
MatrixQW wrote:If a game sets '2' and NVCP '1', who overrides who?
Does the driver always controls the value or can a game override NVCP?
Depends on if the NVCP can override the game's MPRF value, and we'd only know that for sure if each and every game was tested (with high speed setup; ugh).
MatrixQW wrote:With g/v-sync 'off' and stable fps > hz, will that result in pre-rendered frames '0', or that only happens when stable fps < hz?
Theoretically, that behavior should apply with any syncing method (or lack thereof) when the FPS is sustained above an FPS limit, either above or below the refresh rate, but it could vary. I haven't personally tested every possible combination.
(jorimt: /jor-uhm-tee/)
Author: Blur Busters "G-SYNC 101" Series

Displays: ASUS PG27AQN, LG 48CX VR: Beyond, Quest 3, Reverb G2, Index OS: Windows 11 Pro Case: Fractal Design Torrent PSU: Seasonic PRIME TX-1000 MB: ASUS Z790 Hero CPU: Intel i9-13900k w/Noctua NH-U12A GPU: GIGABYTE RTX 4090 GAMING OC RAM: 32GB G.SKILL Trident Z5 DDR5 6400MHz CL32 SSDs: 2TB WD_BLACK SN850 (OS), 4TB WD_BLACK SN850X (Games) Keyboards: Wooting 60HE, Logitech G915 TKL Mice: Razer Viper Mini SE, Razer Viper 8kHz Sound: Creative Sound Blaster Katana V2 (speakers/amp/DAC), AFUL Performer 8 (IEMs)

MatrixQW
Posts: 278
Joined: 07 Jan 2019, 10:01

Re: Pre-rendered frames etc. (continued from G-Sync 101 arti

Post by MatrixQW » 01 Feb 2019, 12:27

Got it! Thank you.

Now, about g/free-sync,

g-sync 'on' + v-sync 'off' + 144hz + 141fps + MPRF '1'

Would this be the smoothest and lagless experience if fps are steady at 141?

MatrixQW
Posts: 278
Joined: 07 Jan 2019, 10:01

Re: Pre-rendered frames etc. (continued from G-Sync 101 arti

Post by MatrixQW » 01 Feb 2019, 12:34

Seems like from Litzner post that Overwatch overrides NVCP because it gets less input lag with 'reduced buffering'.
So the game must be using MPRF '2' and even if NVCP has '1' it stays at '2' and when 'reduced buffering = on' it sets MPRF '1'.

User avatar
RealNC
Site Admin
Posts: 3737
Joined: 24 Dec 2013, 18:32
Contact:

Re: Pre-rendered frames etc. (continued from G-Sync 101 arti

Post by RealNC » 01 Feb 2019, 12:37

jorimt wrote:
MatrixQW wrote:One thing i never really got clear is if this setting works with v-sync off.
I've never tested this directly, but my current understanding/strong assumption is, yes, pre-rendered frames are still in effect with V-SYNC off. Maybe someone else here can tell you for certain.
Yes, it is not related to vsync. It will have an input latency increase with any kind of GPU bottleneck. Vsync is one source of GPU bottleneck. Having the GPU being completely maxed out is the other way to get such bottlenecking. In both cases, the CPU runs ahead of the GPU and piles up input lag.

You can test it by running a GPU heavy game in 4K, everything maxed out, but vsync OFF. This will completely overwhelm any GPU out there. You should see a big difference between MPRF 1 and 8. (You can set it up to 8 in inspector.) But again, some games suffer more from this than others. For example, it might not be affecting Overwatch much, but it seems to hugely affect Witcher 3.
SteamGitHubStack Overflow
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.

User avatar
jorimt
Posts: 2481
Joined: 04 Nov 2016, 10:44
Location: USA

Re: Pre-rendered frames etc. (continued from G-Sync 101 arti

Post by jorimt » 01 Feb 2019, 12:53

MatrixQW wrote:g-sync 'on' + v-sync 'off' + 144hz + 141fps + MPRF '1'

Would this be the smoothest and lagless experience if fps are steady at 141?
Most "lagless" VRR experience at that refresh rate, yes, "smoothest," no.

You'll still experience tearing with G-SYNC + V-SYNC "Off," notably near the bottom of the screen at a constant 141 FPS @144Hz, and you'll experience full tearing during frametime spikes (asset loads, etc).

G-SYNC + V-SYNC "On" fixes this, and with virtually no appreciable input lag increase (sans the removal of tearing).
(jorimt: /jor-uhm-tee/)
Author: Blur Busters "G-SYNC 101" Series

Displays: ASUS PG27AQN, LG 48CX VR: Beyond, Quest 3, Reverb G2, Index OS: Windows 11 Pro Case: Fractal Design Torrent PSU: Seasonic PRIME TX-1000 MB: ASUS Z790 Hero CPU: Intel i9-13900k w/Noctua NH-U12A GPU: GIGABYTE RTX 4090 GAMING OC RAM: 32GB G.SKILL Trident Z5 DDR5 6400MHz CL32 SSDs: 2TB WD_BLACK SN850 (OS), 4TB WD_BLACK SN850X (Games) Keyboards: Wooting 60HE, Logitech G915 TKL Mice: Razer Viper Mini SE, Razer Viper 8kHz Sound: Creative Sound Blaster Katana V2 (speakers/amp/DAC), AFUL Performer 8 (IEMs)

Post Reply