Blur Buster's G-SYNC 101 Series Discussion

[kurtextrem]

A tiny tiny thing is missing from the list:
Most G-Sync monitors have a different LED color when G-Sync is active. By default, G-Sync mode seems to be always on (Not sure why, and not sure if there is any downside to it such as increased energy intake?) and the LED is red.
This can be disabled by using Nvidia Inspector: https://forums.geforce.com/default/topi ... s-active-/ - after a reboot the LED stays white until you go fullscreen on whatever game/program/app.

[Chief Blur Buster]

A tiny tiny thing is missing from the list:
Most G-Sync monitors have a different LED color when G-Sync is active. By default, G-Sync mode seems to be always on (Not sure why, and not sure if there is any downside to it such as increased energy intake?) and the LED is red.
This can be disabled by using Nvidia Inspector: https://forums.geforce.com/default/topi ... s-active-/ - after a reboot the LED stays white until you go fullscreen on whatever game/program/app.

Just to be clear, to eliminate confusion: There's a LED on the monitor in the GSYNC Input Lag article. For that specific particular LED, that's a separate LED. It's not a monitor native LED in the article -- this one is a homemade LED setup with a modified mouse with a LED wire directly to the left mouse button trigger (directly soldered!). This specific LED is intentionally temporarily taped to the left edge of the 240Hz G-SYNC monitor for high-speed-video purposes.

This allows reliable button-to-pixels input lag measurements via high speed video.

It captures the whole latency change from the human's mouse click, all the way to the visibility of pixels on a display.

Mouse lag, game lag, display lag, everything is captured in a "button-to-pixels" input lag test.

This allows us to compare VSYNC ON, VSYNC OFF, GSYNC, different frame rate caps --

Jorim's done a great job. He spent 2 months analyzing many hours of high speed video of a 240Hz G-SYNC monitor (Acer XB252Q).

[kurtextrem]

Hey Chief, that's not really what I meant. It was just an addition - a 101 article sounds like "complete article" and that part was 'missing'. (In case you're confused too: I'm talking about a monitors' LED that is on when the monitor is on, blinking when the monitor is in standby, red when it has G-Sync enabled and so on)

[RealNC]

I don't see why g-sync would have an impact on power consumption. The g-sync module is always active, even in non-gsync mode. VRR is only one of the functions of the module (the module is the "controller" of the panel; all monitors need one, and in this case, the g-sync module serves that role.)

[jorimt]

A tiny tiny thing is missing from the list:
Most G-Sync monitors have a different LED color when G-Sync is active. By default, G-Sync mode seems to be always on (Not sure why, and not sure if there is any downside to it such as increased energy intake?) and the LED is red.
This can be disabled by using Nvidia Inspector: https://forums.geforce.com/default/topi ... s-active-/ - after a reboot the LED stays white until you go fullscreen on whatever game/program/app.

Oh, I see why the Chief could initially misread this. Okay, so you're talking about the LED indicator built into most G-SYNC monitors to let the user know if/when it is active or not? If so, I did not include that, because behavior varies by monitor (I have mine off, in fact, and they never appear to work very well/accurately as is).

About G-SYNC always being active, that's not entirely true. I don't believe it is active on the desktop, even when enabled, for instance. It can, however, as noted in the "Control Panel" page, be active/inactive on certain open application windows with "Enable G-SYNC for windowed and full screen mode" applied.

So, yes, that DWM.exe fix "can" work, but not in all cases, which is another reason I didn't include it. Windows 10 apps appear to run in the new DX12-style fullscreen mode, which means even if you have the borderless/windowed G-SYNC setting disabled and the fullscreen setting enabled, some apps are still affected by G-SYNC, and cause the display to bug out.

For instance, if I have G-SYNC enabled (full screen mode only) and try to put the Windows 10 Crunchyroll app in fullscreen, it's incompatible with G-SYNC and causes the screen to freeze, even with DWM.exe "fix" in place, as the fullscreen mode being used by the app bypasses the DWM compositor.

[Chief Blur Buster]

We'll need to do some deep tests with windowed GSYNC sometime.

Even in windowed mode, GSYNC globally affects the whole screen based on the foreground window. So windows alongside the foreground window are "brought along for the VRR ride" with some weird results.

For example, if I run a GSYNC window at the same time as Google Chrome http://www.vsynctester.com or http://www.testufo.com -- it runs kind of amok (Chrome is not currently designed for VRR operation) but displays the current refresh rate. TestUFO changes the framerate but it stutters like mad. When the videogame says 87fps, TestUFO says 87fps and is unable to detect current Hz. But framerate of the TestUFO window stays (semi-imperfectly) in sync with the framerate of the windowed GSYNC game!

The framerates immediately go back to normal when I exit the windowed GSYNC. My specific display (PG278Q) stays in GSYNC mode throughout the whole hoopla. I am wondering if a change was made to Windows to always synchronize to GSYNC maximum rate whenever "not slowing down" for a windowed game. There's some really weird black-box sheninigians going on inside Windows/drivers that we need to aim high speed cameras, logic analyzers & photodiode oscillocopes at this year. (Sometimes dwm.exe is a Pandora Box, not a black box, alas...)

One thing I think operating systems are probably beginning a long-term migration path to be always in VRR mode, but run at max Hz by default.

Basically treat it like a fixed-Hz mode at the maximum refresh rate. Meaning, 144Hz GSYNC same as 144Hz fixed-Hz. Theoretically & mathematically it can be designed (at the dwm.exe level) to be identical lag, identical scanout. Theoretically, 144fps@144Hz GSYNC is identical (scanout-wise, lag-wise, and DWM-wise) to 144fps@144Hz non-GSYNC. Originally it was 144Hz non-GSYNC when in desktop mode but now my monitor reports it stays in GSYNC mode whenever I enable windowed GSYNC apps. It's possible "144fps@144Hz GSYNC" is technically identical (video-signal-wise) to "144fps@144Hz non-GSYNC".

With the ability to let the Hz fluctuate immediately upon a windowed GSYNC app. This can have weird results on applications forced to go along on the variable-refresh ride. The VSYNC callback rates (by the application in foreground) is forced to all applications on the entire screen that uses VSYNC callbacks. You could reliably assume that refresh rates (VSYNC callbacks) was like a reliable tick-tock, a clock, a metronome -- and a very accurate one! This is no longer true with VRR -- your application might now be forced with random VSYNC intervals if another window, in the foreground, on the same monitor is running in GSYNC mode.

[jorimt]

Yes, there are also some quirks with mixed refresh rate dual/multi-monitor setups. For instance, a 60Hz non-G-SYNC display as a secondary to a 144Hz G-SYNC display as primary. This can produce some strange behaviors as well.

On my current 144Hz primary G-SYNC/240Hz secondary G-SYNC setup, if I don't set "Preferred refresh rate" to “Application-controlled” while playing Overwatch on my 240Hz display, it will inherit the 144Hz refresh rate from my primary.

I couldn't include this info in the article because it's too specific to the given configuration. A good reason to have a topic like this for these nuanced discussions instead.

I'm not sure if the problem is directly on Microsoft's end or Nvidia's (or a little of both), but it should be possible to correct.

[kurtextrem]

Another quirk is stuttering when having an application open on the 2nd screen (I think someone else posted that in the old thread). Nothing on the 2nd screen: No stutter with G-Sync, TS/Discord/Skype/Whatever on it: Stutter.

[Glide]

Great article, though I'm confused about one thing with the testing.
At one point you say that you disabled Windows 10 Game Mode and the "Fullscreen Optimizations" but further down the page you say that you were using "the latest public build of Windows 10 with out-of-the-box settings".
Do you know which it was?

Both Overwatch and CS:GO are on the list of games which use the new optimizations: https://forums.xbox.com/en-us/thread/8d ... 06c2942dad

These new optimizations basically make Borderless Windowed Mode act like Fullscreen Exclusive Mode, where disabling V-Sync allows tearing - just like DX12 UPW games.
I wish that there was some way to force it to work in other games, instead of just a whitelist like it is now.
I'm not sure if this is also the same presentation mode used for <DX9 games on Windows 10, or if they just act like standard Borderless Windowed Mode games. (extra lag)

Most G-Sync monitors have a different LED color when G-Sync is active. By default, G-Sync mode seems to be always on (Not sure why, and not sure if there is any downside to it such as increased energy intake?) and the LED is red.

Doesn't that just happen when you enable Windowed Mode G-Sync?

[jorimt]

Great article, though I'm confused about one thing with the testing.
At one point you say that you disabled Windows 10 Game Mode and the "Fullscreen Optimizations" but further down the page you say that you were using "the latest public build of Windows 10 with out-of-the-box settings".
Do you know which it was?

I do, but I can see how that would confuse you. I was using out-the-box-settings sans "Game Mode." I will clarify that in the article. To be clear, I never had Game Mode, Game DVR, or fullscreen optimizations enabled for the test games during actual tests in the article.

Both Overwatch and CS:GO are on the list of games which use the new optimizations: https://forums.xbox.com/en-us/thread/8d ... 06c2942dad

These new optimizations basically make Borderless Windowed Mode act like Fullscreen Exclusive Mode, where disabling V-Sync allows tearing - just like DX12 UPW games.
I wish that there was some way to force it to work in other games, instead of just a whitelist like it is now.
I'm not sure if this is also the same presentation mode used for <DX9 games on Windows 10, or if they just act like standard Borderless Windowed Mode games. (extra lag)

I did "off the record" tests of Game Mode and posted the results in my original thread on May 26th:
http://forums.blurbusters.com/viewtopic ... 260#p26491

As an aside while I continue my tests, I did several quick single run Creators update "Game Mode" G-SYNC + V-SYNC + -2 FPS limit @144Hz tests in Overwatch (at lowest settings) up against non-Game Mode G-SYNC + V-SYNC + -2 FPS limit @144Hz.

Scenarios as follows:

1. Fullscreen Optimizations Enabled
2. Fullscreen Optimizations Disabled
3. Game Mode (Settings) + Fullscreen Optimizations Disabled
4. Game Mode (Settings) + Fullscreen Optimizations Enabled
5. Game Mode (Settings) + Game Mode (Game bar) + Fullscreen Optimizations Enabled
6. Game Mode (Game bar) + Fullscreen Optimizations Enabled

The results? No input latency differences on my system. Granted, I had no background programs running, no overlays, CPU was unparked and at highest frequency, and I do have very decent specs, so the gains would likely only show on weaker configurations or systems that multi-task, but it still doesn't explain how Battle(non)sense's results show a significant global reduction in input latency, and solely with the Game Mode toggle in the Windows settings. Go figure.

The only difference I did observe with fullscreen optimizations, is that with it disabled, the screen would flash twice in exclusive fullscreen when trying to bring up the Game bar (which signifies it is supported, but can't be brought up because of exclusive fullscreen mode), and with fullscreen optimizations enabled (default), the Game bar could be brought up with the keyboard shortcut, even in exclusive fullscreen mode.

Anyway, since Game Mode tests won't be included in the upcoming article (off-topic), I thought I'd post about my findings (albeit not in the least ways in-depth or conclusive) here. It definitely appears that the Game Mode setting's effectiveness depends entirely on the setup. It would probably be very difficult to isolate consistent differences and come to any definitive conclusions from testing a single system.

As I stated in the borderless/windowed test section of my article (which I'm not ready to "call" yet, until further testing/corroboration; there could be more factors than I accounted for), no combination of any setting could get the screen to tear in either mode. So I don't think it's quite as simple as Game Mode turning borderless/windowed into the DX12 version, otherwise I would have seen, one, tearing, and two, no added 1 frame of delay from the DWM with the non-G-SYNC scenarios in my tests.

So there's more to it, and/or what others were reporting was a temporary bug or quirk fixed in later Windows patches, or it is at least a behavior limited to specific games or system configurations, because I couldn't replicate any of it.

Bottm-line, borderless/windowed G-SYNC did not add 1 frame of delay, non-G-SYNC did (Game Mode on or off).