Strange behavior I just noticed with Overwatch 2

[drmcninja]

This may be unrelated to the game.

So OW2 has the frame cap at 600fps (or whatever you set below that). OW1 was at 400.

I have a 360Hz monitor with framecap set at 358 with G-Sync on, V-Sync off.

In OW1 I clearly noticed an improvement in clarity with both G-Sync and V-Sync but decided just G-Sync was good enough (to avoid additional input lag). FWIW, I was comparing it to 400fps, 360Hz.

Now, in Overwatch 2, I noticed a few things:

- If G-Sync is on, but I set FPS cap at 600, the refresh rate of the monitor stays at 359Hz... and even randomly dips as if the fps was going under that number, but the FPS is pegged at 500+! I can't tell if this also happens in OW. If I disable G-Sync in NVCP, then refresh rate stays at 360Hz and doesn't change.

- Tearing is much more difficult to notice in OW2 than OW1. This may also be due to the different graphics, darker or more contrasted objects, etc. So difficult to notice in fact that I can sometimes no longer tell if any framesync is active or not.

- FastSync is suddenly noticeably laggy... even more so than V-Sync under 360fps. How is this possible? I have to assume this is in my head? FastSync 600fps 360Hz should have less input lag than V-Sync on 360Hz, 358fps...

Did they change something with how the engine implements framesync technologies here? Nvidia was advertising OW2 and bragging about how Blizzard moved the framecap to 600 so the new 4000 series graphics cards could stretch their legs. Is it possible Blizzard did something to make it tear less or keep G-Sync somehow working, even when fps goes over refresh rate?

[jorimt]

Is it possible Blizzard did something to make it tear less or keep G-Sync somehow working, even when fps goes over refresh rate?

I can't directly speak to engine changes, or any of your other observances since I haven't played or tested OW2, but what I can definitively answer now is G-SYNC doesn't work with framerates above the refresh rate and never can, regardless of the game engine.

I may download OW2 at some point and try to replicate what you're seeing. If I do, I'll be sure to respond back here for any possible explanations (no ETA).

[drmcninja]

Thanks!

Yeah, it's weird as hell. My FPS in-game is at 550-600, no dips, and the monitor's OSD refresh rate display is showing 359Hz with random fluctuations below. So G-Sync is active, but what it is syncing to, I have no idea.

[jorimt]

My FPS in-game is at 550-600, no dips, and the monitor's OSD refresh rate display is showing 359Hz with random fluctuations below. So G-Sync is active, but what it is syncing to, I have no idea.

This is with "360Hz monitor with framecap set at 358 with G-Sync on, V-Sync off," correct? If so, is it the in-game frame limiter, or?

[drmcninja]

My FPS in-game is at 550-600, no dips, and the monitor's OSD refresh rate display is showing 359Hz with random fluctuations below. So G-Sync is active, but what it is syncing to, I have no idea.

This is with "360Hz monitor with framecap set at 358 with G-Sync on, V-Sync off," correct? If so, is it the in-game frame limiter, or?

No, when I set it as you describe, but then turn off in-game framecap so FPS shoots to 600, the refresh rate of the monitor is still 359Hz and fluctuates as if G-Sync is active. But FPS is well over 500.

[jorimt]

No, when I set it as you describe, but then turn off in-game framecap so FPS shoots to 600, the refresh rate of the monitor is still 359Hz and fluctuates as if G-Sync is active. But FPS is well over 500.

I just managed to replicate this with G-SYNC on + V-SYNC off + a 600 FPS in-game limit, and it did the same thing for me...but it's normal in this scenario.

G-SYNC on + V-SYNC off means whenever your framerate exceeds the refresh rate, G-SYNC behavior disengages and it reverts to no-sync behavior until the framerate dips below the refresh rate, at which point G-SYNC behavior re-engages, hence the typical recommendation to use a minimum -3 FPS limit (even when the V-SYNC option isn't paired with G-SYNC) as to keep the framerate within the VRR range and maintain G-SYNC behavior.

As for the refresh rate meter on your monitor still fluctuating in this scenario, any momentary frametime dips (not always caught by monitoring overlays like Afterburner) may fall within the G-SYNC range again, causing fluctuations below 360 Hz to appear on the meter. It did the same for me on my 240 Hz monitor.

[rootsoft]

If you are using Riva Tunner, try closing it. I had random stutters while it was open, not even using the limiter.

[Chief Blur Buster]

This may be unrelated to the game.

So OW2 has the frame cap at 600fps (or whatever you set below that). OW1 was at 400.

I have a 360Hz monitor with framecap set at 358 with G-Sync on, V-Sync off.

Frame rate cap should be at least ~3% of the frame rate. For 360Hz, you should use a cap of 350.

The more inaccurate the frame rate cap algorithm in the game, the bigger % margin below max Hz you need to avoid latency and tearing problems. You may need 5%-6% in some games with less accurate cap algorithms, so in that case, set your cap to 340 or so.

This is because some refresh cycles are 1/340sec and other refresh cycles are 1/370sec. The 1/370sec frametimes will "collide" with a monitor busy refreshing, forcing the frame to wait until the refreshing is finished. If it's a DPC call, there can also be an additional latency between the end of a refresh cycle, and the start of a new refresh cycle. Unfortunately graphics drivers don't always immediately begin refreshing a new refresh cycle if (A) the frame was blocked by a monitor-busy-refreshing, and (B) the CPU and GPU are under intense load, which can cause (C) refreshing to occur a slight delay (a millisecond or so) after the previous refresh cycle finished refreshing.

You have to prevent that from happening, since if the CPU/GPU is under intense load, a DPC-triggered refresh cycle (bigger problem with FreeSync or G-SYNC Compatible, than with G-SYNC Native) might have a slight delay.

You don't want to "tailgate" the refresh cycles too closely, so give more distance between the previous/next refresh cycles, by using a bigger capping margin when using higher Hz. 3fps-below is too small % at the 360Hz stratospheres! It takes time to switch between in-VRR-range mode and out-of-VRR-range modes, which creates lagfeel inconsistency and high lagfeel, so always, always, always err on having too much capping margin.

It may not be necessary if your GPU and CPU load is low, and the game is flushing the frames efficiently (instant start of next refresh cycle after end of previous refresh cycle ends), and the monitor VRR technology + driver implementation has an ultra-low latency switching between in-VRR-range and out-of-VRR-range logic. Even game differences (OW1 vs OW2) have enough framerate-cap algorithmic differences to create bigger latencies during same-capping-safety-margin situations.

Then theoretically, too-tight cap margins will have almost no lagfeel penalty. But in the real world, real VRR drivers, real VRR monitors, and real games, have nitpicky behaviours, plus framerate caps are never perfect (358 cap = usually average-based algorithm = some frames are 1/350sec and some frames are 1/370sec), so you need a bigger cap safety margin with more noisy cap algorithms. This is an issue even for GSYNC + VSYNC OFF too, and besides, overloaded CPU/GPU adds other latencies other than VRR-related latencies anyway, so it's still good practice to cap in a way to prevent CPU100%, GPU100% -- that will leave some CPU cycles to process your mouse clicks faster. So reducing framerate by a few percent often reduces latency.

Clearly, the OW1 vs OW2 swapchain-frequency-throttling-algorithm (aka "framerate cap in a C++ subroutine") is implemented slightly differently in these engines, and is triggering "issues"...

The old "2fps below" and "3fps below" can add fatal latency when it's far less than 1% safety margin to the VRR range max Hz. The 3fps below was great in the 144Hz days but terrible advice for the 360Hz days.

The old boilerplate "3fps below" advice needs to be replaced with a "3-5% below" advice. That's why NVIDIA Reflex Latency Analyzer uses bigger margins -- to avoid this increased lag caused by a too-small cap differential!

Also remember this folks: The rendering latency difference of 350fps versus 360fps is ((1/350)-(1/360)) = 79 microseconds = 0.079 milliseconds. Why the hell are you doing 358 instead of 340 or 350?

I guess maybe I need to hire jorim for a GSYNC 202 article (sequel), eh?

[gameinn]

I guess maybe I need to hire jorim for a GSYNC 202 article (sequel), eh?

Wouldn't be a bad idea. Especially in relation to OW2. There was alot of people complaining about how weird OW2 felt aim wise compared to OW1. People saying stuff like switching to AMD FSR but putting the slider to 0% helped aim. Could get some good attention for the site especially since the game is F2P now.

I've had some weird behavior with the game that it's got to a point that I'm like the I have no idea what I'm doing dog. I still can't decide if running like 400 fps instead of utilizing G -Sync is better.

I have a LG 1440P 180Hz screen but the game just feels weird to me compared to OW1. I've thought about getting back out my Alienware 240Hz screen to see if it feels different. So you would say g sync cap for 180Hz should be 174?

One thing I noticed when trying to diagnose the issue was Nvidia Reflex. If I enable Nvidia reflex or enabled + boost and open up SIM on the game my right number shoots up to like 10 sometimes (usually it's 5.7 for 176 fps). If I disable reflex completely then all 3 SIM numbers relatively stay at exactly 5.7. Maybe the occasional right number going to 5.8 but that's about it.

How I understood it is reflex only gets "enabled" if my GPU is close to max load but at 1440p and around 180 fps on a 3070 that isn't happening especially in the practice range. Why is the SIM changing so drastically?

[jorimt]

The old boilerplate "3fps below" advice needs to be replaced with a "3-5% below" advice. That's why NVIDIA Reflex Latency Analyzer uses bigger margins -- to avoid this increased lag caused by a too-small cap differential!

Yeah, but many visitors already barely read my G-SYNC 101 article (if at all) before jumping straight into my comments section to ask me a question that is usually already answered in said article.

And while they usually know the "-3 FPS" recommendation, many of them only do from a reddit or forum post about my article, and even then they don't always know why it should be used, that it is relative to their refresh rate, that it is a "minimum" recommendation, and that it is exclusive to G-SYNC and should not be used for no-sync or standalone V-SYNC.

So all that said, I wonder what hilarity of confusion would ensue if I swapped that already misunderstood "-3 FPS relative to your current max physical refresh rate" recommendation out with "3-5% of your current max physical refresh rate" (which I agree with for 240Hz+).

"Get out your calculators people, time to do some formulas!..."

Also remember this folks: The rendering latency difference of 350fps versus 360fps is ((1/350)-(1/360)) = 79 microseconds = 0.079 milliseconds. Why the hell are you doing 358 instead of 340 or 350?

Agreed, but the psychology of numbering is strong with the uninitiated; MOAR = better

I guess maybe I need to hire jorim for a GSYNC 202 article (sequel), eh?

Selectively updating the existing article (as I already occasionally do) when and where warranted, sure.

A "202" on the other hand may be more suited to standalone articles (and I've got a day job, so who knows if/when I have the time for those), especially if you throw methods not entirely related to G-SYNC operation into the mix; Reflex, game-specific settings, etc.

One thing I noticed when trying to diagnose the issue was Nvidia Reflex. If I enable Nvidia reflex or enabled + boost and open up SIM on the game my right number shoots up to like 10 sometimes (usually it's 5.7 for 176 fps). If I disable reflex completely then all 3 SIM numbers relatively stay at exactly 5.7. Maybe the occasional right number going to 5.8 but that's about it.

As I've previously described to another user in the forums:
viewtopic.php?f=5&t=3441&p=78408&hilit=SIM#p78408

this is what those numbers per slash represent:
SIM min frametime/ avg frametime/ max frametime/

The average frametime with Reflex enabled in your capture is 6.3ms, which almost perfectly aligns with the average frametime of 157 FPS at 6.4ms, whereas the average frametime with Reflex disabled and a 164 FPS limit in your capture is 6.1ms, which is the average frametime of 164 FPS.

So what you're seeing is entirely expected

The "10" number you're seeing means the frametime has reached a maximum of 10ms with Reflex enabled in the current session, which is from an average framerate of 100 FPS.

Since Reflex uses a dynamic FPS limit to prevent GPU usage from maxing, something in it's behavior may briefly engage the dynamic limit during the larger frametime spikes/variances, causing what I assume would be a relatively benign effect if you're system is already momentarily dropping to 100 FPS during said variance (which is usually too brief to be picked up by overlays like Afterburner due to polling report limitations).