G-Sync requiring very low FPS cap?

[RealNC]

Yep, looks like something broke in recent RTSS versions then.

My alternative is Dxtory:

http://exkode.com/dxtory-downloads-en.html

It's as low-latency as RTSS. So if that works, then use that until RTSS gets fixed. The NVidia limiter adds additional input lag, which is why I don't recommend it. It's basically nullifying g-sync's low latency. (For reference: RTSS and Dxtory add up to 1 frame of input lag, the NVidia limiter adds 2 frames of input lag.)

To use Dxtory as a pure frame limiter, simply disable all its video capture features (I unbind all shortcuts), and just check the "Limit Video FPS" box in the "Advanced Setting" tab (third from the right.)

And if you test Dxtory, please keep us posted. We'd like to know if its also broken or not, as other users might run into the same issue

[Glide]

Same problem with Dxtory.
Dxtory's OSD at least reports some of the framerates above the cap though, unlike RTSS.

I assume that I would be better off just allowing the game to run at 100Hz uncapped than using NVIDIA's Framerate Limiter though, since it seems to add as much latency as V-Sync - and possibly more than V-Sync on a G-Sync display?

[jorimt]

Hm @Glide, you may be onto something. Do you have the Creator Update installed on Windows 10 by any chance?

I do, and just did some testing in Overwatch on two separate G-SYNC monitors, and with either the built-in cap or RTSS, the refresh rate meters would occasionally spike to the max refresh rate of the display, regardless of the framerate limit.

I tested this with game mode/game bar off (never have them on), and also enabled/disabled the "fullscreen optimizations" option newly introduced in the Creator's update, and the behavior didn't change. I could be wrong, but I don't remember this behavior before the Creator's update. I know they changed some system DLL files.

I'd test it without G-SYNC, but then obviously the built-in meters don't read any fluctuations, as the refresh rate remains constant.

I was going to start my input latency re-tests tonight, but I may have to hold off until this is resolved. Regardless, I will probably do a couple of quick tests to see if these apparent spikes have any impact on input latency. Hopefully the Creators update is simply causing the built-in meters to report inaccurate refresh rate readings for whatever reason.

[Glide]

Yes, I'm using the Win10 CU and have tried those settings too.
I just built a new PC so I haven't used G-Sync with anything else.

[jorimt]

I just did a couple of quick tests in CS:GO (left click look method, 10 samples per)...

V-sync off + fps_max 98 (100 Hz):
AVG: 28ms
MIN: 24ms
MAX: 33ms

G-SYNC + V-sync on (Nvidia Control Panel) + fps_max 98 (100 Hz):
AVG: 32ms
MIN: 27ms
MAX: 37ms

Difference:
AVG: 32 - 28 = 4ms
MIN: 27 - 24 = 3ms
MAX: 37 - 33 = 4ms

Accounting for my error margin of <1ms, along with possible variances between multiple runs (I only did a single run with 10 samples each scenario for this test), and the difference is likely a maximum of 1-2ms between the two, and only in certain areas of the screen; frames render to the middle of the screen at virtually the same time in both scenarios.

Seeing as frames at 100 Hz render in 10ms, the conclusion is there is no sync-induced input latency (nothing close to full frames worth) with G-SYNC + v-sync on + in-game 98 fps limit vs unsynced at the same framerate limit, even when the built-in refresh rate meter reports a 100 Hz spike.

Any increase, however slight (1-2ms max) is due to G-SYNC frametime compensation preventing tearing in the upper fps range; G-SYNC + v-sync off + in-game 98 fps limit would tear in the same instances.

This, of course, is not an exhaustive test (those are coming up in my next G-SYNC 101 article entry), but all appears to be expected behavior, even with this apparent refresh rate meter glitch.

[RealNC]

I just tried Dishonored. RTSS is unable to cap this game, if I run the game with RTSS already running.

If I quit RTSS, start the game, and start RTSS afterwards, the cap works.

Can you test if this is the issue you're running in? Quit Afterburner (quitting RTSS with Afterburner running doesn't work) before starting the game. Then alt+tab to the desktop and start RTSS.

I did a FRAPS bench, and the graph doesn't look good :-/ Anyway, FRAPSLOG.TXT says:

Code: Select all

Frames: 3189 - Time: 35047ms - Avg: 90.992 - Min: 90 - Max: 92

So I'm not sure how the frametime data are to be interpreted.

Also, in case you didn't know, Dishonored has its own frame limiter, which is zero-lag. Go to:

My Documents\My Games\Dishonored\DishonoredGame\Config\DishonoredEngine.ini

And in that file, search for "bSmoothFrameRate". Make sure you have these values:

Code: Select all

bSmoothFrameRate=TRUE
MinSmoothedFrameRate=30
MaxSmoothedFrameRate=98

The "MinSmoothedFrameRate" value doesn't matter. The cap is given by the "max" value.

(I assume here we're talking about Dishonored, btw, NOT Dishonored 2.)

[Glide]

Strange, RTSS works just fine for me if it's already running before I start the game.
Using the game's framerate limiter I still have to cap it to 92 FPS to prevent it from ever hitting 100 during gameplay.

Is that all the "smooth framerate" option does though? At least when it's inside the specified range.
There's also a "OneFrameThreadLag" option for UE3 games which I've heard can reduce latency further if you disable it, but I've not seen any measurements.

The game feels really good when it's never allowed to enter a V-Sync on state, but I'm still unsure about whether to cap it this low, or pick something like 98 where it is staying under 100Hz 95% of the time, vs capping at 87-92 depending on the limiter used to prevent it from ever hitting 100Hz.

[RealNC]

The in-game limiter is virtually 0-lag. The Unreal Engine really has one of the best frame limiter implementations out there. So if you hit vsync, it should be noticeable immediately with the mouse.

The "bsmoothedframerate" thing just means the frame limiter is dynamic. For example, if you look one way in the game and your FPS drops to 50, then look the other and normally get 90, it just raises the limit slowly. It doesn't jump from 50 to 90 immediately, but raises it over a period of 1 second or so. This is a good thing, since "jump cuts" in frame rate are too jarring, even with g-sync.

It doesn't affect the frame limiter's latency. But if you don't like the effect (why?) then you can just set both min and max to same value. "bsmoothedframerate" must be "true" in all cases though, otherwise the frame limiter gets completely disabled, no matter what you set the min/max values to.

The "oneframethreadlag" option indeed lowers latency by one frame. This might interfere with multi-threading, which is needed on low-end systems to get acceptable frame rates. On a gaming PC with decent single-core performance, you can enable it. Didn't test it with this game. When I can't tell/feel any input lag in a game, that's where I stop tweaking it further

With all that being said, I had no issues with the frame limiter even before I got a g-sync monitor. I was using a 120.008Hz mode on my non-gsync monitor, and a 120FPS in-game limit gave zero lag. It was never hitting the 120.008 maximum. Same with RTSS. 120FPS cap on a custom 120.008Hz mode, and it gave low input lag (higher than the in-game limiter, of course, but much lower than uncapped vsync.)

So in the end, I can't really explain your results :-/ I suspect it might just be an indicator issue, and there's nothing to worry about. If you can't feel any input lag in Dishonored with an in-game 98FPS cap, then I'd say you're not actually hitting 100FPS, no matter what the monitor's OSD says.

[RealNC]

OK, some news from Unwinder (author of RTSS):

Limiting framerate and logging frametime from two different 3D hook applications is not the best idea as well, you may not see the real picture depending on injection order (which is normally defined by hook application start order).
For example, imagine that FRAPS hooks frame presentation routine first and RTSS is the second in injection chain. If 3D application render frame in 6ms and framerate limit is set to 60FPS in RTSS, then FRAPS will intercept frame presentation first and log it as is, i.e. show you 6ms then RTSS will intercept the frame and spend 10ms waiting to provide 60FPS limit, so frametime before actual frame presentation will be 6+10ms, but you'll see just 6 in FRAPS log.

And he's right. When I launch each program in this order:

1. Start FRAPS.
2. Start the game.
3. Start RTSS.

Then the FRAPS bench shows more stable frame times without huge frame rate spikes.

[Glide]

The latest RTSS beta has an option to update the counters every frame now instead of polling, and the option to disable averaging.
With Afterburner/RTSS being the only overlay injected, and RTSS handling framerate limiting (to 91 FPS) I'm still seeing it miss a lot of drops or times when it exceeds the limiter.





That's not to say that it misses everything though: