Alternative to GSYNC-setting "VSync on + 142fps framelimit". What do you think?

This has been a really interesting discussion to follow chaps. Thankyou.

Quick question: for those of us with no-gsync or freesync, on 60hz, is it worth frame-limiting to 59 with RTSS over simply driver-forcing vsync, or using driver-based Adaptive Sync? Can Adapative and frame-limiting be used together?

I just notice, it seems, with some games despite holding 60fps they're not as smooth as others, as if the pacing is off.

 

With adaptive, a frame cap will disable vsync, since that's what adaptive does: it disables vsync when your frame rate falls below refresh. When you're frame capping, your frame rate falls below refresh.

What I've been doing on 60Hz monitors is the "low latency vsync" trick. You enable vsync and cap to slightly below refresh (which is not actually exactly 60Hz, btw, even on 60Hz monitors.) About 0.007FPS lower does the trick. RTSS is needed, as it is capable of such accurate frame capping.

I posted about this here:

http://forums.guru3d.com/showthread.php?p=5380262#post5380262

This allows you to have acceptable levels of input lag with 60Hz vsync. It's not going to be as good as g-sync or vsync off input lag, but better than default vsync.

 

Thanks for the response. I figured I should just start playing with it and see, using the latest 7.0.0 beta.

Capping to 59 works fine, but I get tearing. Tried with: adaptive (as you explained, no surprise there), vsync off (also no surprise), but also with sync on. All tear. Is that expected? I'll check out your guide.

I run SLI if that has any bearing.

 

Capping to 59 works fine. The issue is that it gives you microstutter (one frame is duplicated every 59 frames.) It's a small "hiccup" that occurs exactly once per second. The only point of capping to 0.007FPS below refresh is to get rid of that hiccup.

I'm not sure if SLI has any effect on this. I've never ran SLI myself and thus have no idea if it behaves differently.

If you force vsync on, then you should not get any tearing, regardless of whether you're frame capping or not. If you get tearing, then that means vsync (for whatever reason) is not enabled. Perhaps you didn't force it in the control panel, or you have it disabled in a per-game profile.

Edit: if your monitor can be convinced to run at 75Hz, that would also provide a big latency difference. 15Hz more doesn't sound like much, but actually, it makes a big difference. To test that, you need CRU to add a 75Hz mode and the NVidia or AMD pixel clock patcher to force the driver to allow that refresh over single-link DVI. I've been doing that for years on my old Samsung XL2370 monitor, and it improved things considerably, both for input lag as well as for motion clarity.

 

I followed the guide, still getting tearing -- but then I was using a sample size of 1: Natural Selection 2.

So tried a few other games - Dying Light, Abzu (great test for this as you can spin fast and easily see any tearing) and no tearing at all. Natural Selection 2 is doing something funny when RTSS is enabled -- tried with driver vsync, NS2 vsync, always tearing if RTSS is frame capping.

So that must be an isolated incident, the other games testing fine so far

Edit: So now a question becomes, can I blacklist in RTSS as opposed to whitelist? So keep global always on, but disable for eg with NS2. I can add the NS2.exe for a profile, but I believe lowering the detection level isn't going to stop it hooking.

This is on a 4K LG OLED, not sure it's going to tolerate past 60!

I do have a CF791 100Hz upstairs (where the pc is normally), and absolutely referesh rate makes a huge difference to smoothness and input lag. But oh... the 4k, the OLED, the 55"... *sigh*. Where's the one monitor with it all?

 

Right now the Dell UP3017Q is the closest. It's still 60Hz, but it's an OLED with per-pixel strobing that can be switched between 60Hz and 120Hz. That means motion clarity is pretty much the same as a CRT.

Don't look at the price though... (I warned you, didn't I :cry

 

Its a lot cheaper than it was! It was $5,000 when they first talked about it just like the OLED TVs. Hopefully the prices keep dropping at this rate. Even at $5,000 its 1/4 the price of smaller and lower resolution Sony BVM OLEDs.

 

A, B, C, D, E, F, G-Sync, H, I, J, K, L, M, N, O, P-Sync, Q, R, S, T, U, V-Sync, W, X, Y, and Z-Sync! Now I know my ABC-Syncs! Next time won't you sing with ME-SYNC?

 

I always run G-SYNC + VSync On and have never faced any input lag on my 144 Hz PG278Q or my 240 Hz PG258Q. On my old non-G-SYNC 120 Hz monitor, I was extremely sensitive to VSync input lag even at 120 fps and had to turn VSync off. I have never used a frame limiter, but I noticed that the games top out at 142-143 fps and 238-239 fps on my monitors and never run at 144 fps or 240 fps.

 

Nope 144hz cap on my pg279q, no vsync.

 

Without a frame limiter on a high-FPS game, you're using vsync. That's a fact. If you get 143FPS, that's vsync kicking in.

144Hz vsync lag is quite low though. In most games, it's about 50ms total button to pixel lag. Many people just aren't bothered by this small amount of lag, and thus you're completely fine with vsync.

 

G-SYNC Off + VSync On has intolerable lag at 144 fps, not so much at 240 fps. This implies there is a difference between G-SYNC On + VSync On at 144 fps and just VSync at 144 fps. Maybe it is "perfect" VSync that is time aligned. I'm not sure how this is possible always.

With support from the game engine, it is possible to have perfect VSync. If the engine knows the approximate render time in advance, it can sample the input at the last possible moment and render just in time for VSync with no input lag.

 

I cannot confirm that. And neither can the tests that have been performed thus far. G-Sync + vsync without frame capping has the same input lag as stand-alone vsync without g-sync.

So I have no idea what it is that you're seeing. Does this happen with all games? Only specific ones? Which ones?

 

With G-SYNC and VSync On, my frame rate never reaches 144 or 240. It's always 1 or 2 fps below, without using a frame limiter, so VSync is never kicking in presumably. Even at 143 fps, it does not suddenly introduce additional input lag. But I can instantly see the lag if G-SYNC is off. And I'm not talking about lag when the frame rate drops with VSync. This is in games like CS:GO which run at max frame rate all the time.

 

I'm not saying there is no VSync input delay - it has to be there by the very definition of VSync. However it must be 1/144 or 1/240 ms, and not 50 ms.

With G-SYNC off, then the VSync lag is clearly visible. And it must be in the tens of milliseconds to be visible.

 

This could be just an inaccuracy in the FPS indicator. This also applies to g-sync-based in-monitor FPS displays. Some Asus and Acer monitors have this.

G-sync does not attempt to keep frame rates within g-sync range. This would be up to the game to do, and I'm not aware of any games that do this currently.

One way to test this is to set the "preferred refresh rate" setting in the nvidia panel from "highest available" to "application preference", and switch to 60Hz. 60Hz makes it easier to detect input lag differences between capped vs uncapped frame rate. Capping to 58FPS should have considerably less input lag, while an uncapped frame rate will result in vsync which at 60Hz has massive input lag.

(If your monitor also supports 50Hz, that's even better for testing.)

 

I'll test 60 Hz today. What I don't get is why VSync On produces a worst case delay that is greater than 1/Refresh Rate. G-SYNC has a worst case delay of render time + 1/Refresh Rate, especially if the monitor is duplicating a frame, and that doesn't feel laggy. The only explanation is VSync is broken for some people.

 

Vsync does not cap the frame rate (meaning it does not prevent the game from rendering more frames.) It results in the game rendering frames until all frame buffers and pre-render buffers are completely filled. When that happens, the game sits and waits. Some games are extra bad at this, and they sit and wait on old player input. At the time a buffer becomes free (meaning the frame got scanned out by the monitor), that input is very old. A frame rendered based on that input needs to then wait even more until it goes through the buffer chain. By the time it reaches the monitor, it got REALLY old.

This is called "vsync back pressure." To prevent it, the game needs to stop rendering more frames when it waits for the vsync signal. If it doesn't (and most single player games don't), you need to use a frame rate limiter instead. The limiter blocks the game from rendering extra frames, and thus keeps the frame buffers empty. If there's 5 buffers total for example (the current render buffer, plus one more frame buffer in double-buffered vsync, + 3 pre-render buffers), frame limiting can eliminate 3 of them by keeping them empty. That's a big input lag reduction, especially in 60Hz. This gives you 1 (best case) to 2 (worst case) frames of input lag. Which is the lowest you can get with an external frame limiter with vsync. With g-sync, you get that down to just 1 frame (always the best-case.) With an internal limiter, you can get even lower input lag (less than 1 frame.) "Good" games can do this (fps_max in CS:GO for example, or the frame limiter in Overwatch.)

Note that this only applies when the cap is actually hit. (Both for g-sync and without g-sync.) If you cap to, say, 120FPS but the game renders at 110FPS, you still get the pre-render buffers filling up. This is also testable by setting "max pre-rendered frames" to something like 8 (in Profile Inspector; the nvcp only allows up to 5). If the game does not reach the cap, even if by only 5FPS, you get a massive input lag increase, both with g-sync and without. To minimize the effect, one should not only cap the frame rate, but also set max pre-rendered frames to 1. Input lag sensitive online games usually do this automatically on their own (CS:GO and Overwatch do this.) The vast majority of single players don't. You need to set this to 1 in the nvidia panel.

Hopefully it's now a bit more clear why vsync is not able to give render time + 1/Hz worth of input lag. Only frame capping can do that.

 

I did some programming for PlayStation a decade ago, and there we just call a "wait for Vblank" function that blocked until the scan was complete, and then flipped the only two buffers. So I'm guessing that was somewhat of an ideal situation with a worst case latency of 1/Hz at a locked framerate. There was so little memory that you couldn't afford more than two buffers, and IIRC not even an API to swap more than two buffers. It was such a time accurate system that even 1 frame of button input delay was detectable and would throw off skilled players.

Is this when games have artificial frame rate limits?

 

Everything was simpler back then

Nowadays, you don't get to flip back and front buffers manually. You ask the API to do it (the Present() function in DirectX for example). The CPU and GPU are not synchronous anymore like they were in the PlayStation days. So what happens is that when you call Present() to submit your frame, instead of blocking until vsync, the function actually returns and just adds the operation to the queue. The queue has multiple "wait for vsync and flip" operations in it and they get executed later on.

So the game keeps rendering and Present() will only block if all buffers have filled. At that point, input lag becomes a big factor.

A frame limiter prevents that from happening. In effect, a frame limiter makes it behave like your PlayStation example. It really blocks the game until the vsync. No extra frames are queued. I don't know if RTSS for example is implemented that way, but I would assume what it does is hook into the Present() call, replace it with its own implementation which actually blocks instead of returning. And it seems to do that with a busy wait instead of a sleep (explains the high CPU utilization when render times get very low; the faster the game renders a frame, the more busy waiting RTSS does.)

No, it's when the game just can't render fast enough. If you cap to 20000FPS for example, it's doubtful you will hit that cap.