Page 7 of 33
Re: G-Sync 101 w/Chart (WIP)
Posted: 19 Jan 2017, 20:21
by MT_
RealNC wrote:Then you should not be affected by microstutter.
Fullscreen is always better though in the majority of cases. Even with gsync, the compositor still needs to do compositing, and that adds a tad of delay.
Also, some games can't set up their gamma value in windowed mode. This can make the game look brighter or darker than what the developers intended. Witcher 3 is one of those games, for example.
But in any event, use whatever works best with the specific game. If Mechwarrior Online has crappy fullscreen, then obviously, the best thing to do is use windowed mode!
Also try the executable's properties though and enable the "disable aero" checkbox (right click on the *.exe of the game and select properties.) This is gonna disable compositing when you start the game, but it might give you the best results possible. (Hopefully gsync can work in that mode too.)
I don't think G-sync works without active Aero right? that Compatibility thing simply disables it completely until the game is exited. As far as the topic starter goes, G-sync in windowed manipulates the DWM framebuffer or something.
jorimt wrote:MT_ wrote:Lets say that full screen is half ass job in this game. Alt+tabbing between game and main menu will make it jump back and forth until the game crashes... Unless I provoke task manager in time.
It's possible MechWarrior Online does not feature exclusive fullscreen.
Just to double check, do you have "Enable G-SYNC for full screen mode" or "Enable G-SYNC for windowed and full screen mode?" If you only have the first enabled, G-Sync won't function in windowed or borderless windowed (borderless fullscreen) mode.
I will be testing 60 Hz G-Sync input latency specifically in the future, so I'll try both 58 and 59 fps to see how far it can be pushed before latency is introduced.
I'll be looking forward to it. Yeah I have that enabled as well, and restarted the PC (In my experience it doesnt always work until a restart when you first set it to windowed + fullscreen)
Anyway I think I'm settled for now, thanks for the useful info. I'll just be going on my guts mostly to observe lowest latency and highest FPS

Re: G-Sync 101 w/Chart (WIP)
Posted: 19 Jan 2017, 20:35
by jorimt
MT_ wrote:I don't think G-sync works without active Aero right? that Compatibility thing simply disables it completely until the game is exited. As far as the topic starter goes, G-sync in windowed manipulates the DWM framebuffer or something.
Aero and the DWM (Desktop Windows Manager) are the same thing, so if G-Sync windowed mode is enabled, I doubt that option would have any effect.
I'm running Windows 10, which doesn't have that option, so I can't check myself. You can however. There should be an option in your monitor menu called "Refresh rate num" which will display large yellow numbers representing the current refresh rate of the display. If it stays at "60" at all times in-game (even during start-up/load screens), G-Sync isn't enabled. If it fluctuates at any point in-game (<60), G-Sync is working as intended.
MT_ wrote:Anyway I think I'm settled for now, thanks for the useful info. I'll just be going on my guts mostly to observe lowest latency and highest FPS

Alright, feel free to chime in with further input or questions whenever
EDIT: on a side note, I tested it, and MechWarrior Online does have exclusive fullscreen support.
Re: G-Sync 101 w/Chart (WIP)
Posted: 22 Jan 2017, 12:26
by jorimt
I was browsing the Geforce forums and found this post referencing Battle(non)sense's latest video:
Looks like in his testing, RTSS adds 1 frame of input latency over the in-game cap with G-Sync enabled. Obviously, my test results show no difference in input latency. We're using very similar method's as well, so I don't see a problem there.
So, either he has too low a sample count (he doesn't say what it is), he's calculating incorrectly (I find that unlikely), or something else is going on, though I'm not sure what. I guess it's possible there could be a difference in the module between the models, or a difference in TN over IPS, but I don't see how. Or possibly a system difference in frametime delivery. Or, maybe I did something wrong, but I went through a ton of scenarios/samples with the identical methods/settings, and had a proper control, so I don't see what.
If you happen to see this @Sparky, I've seen you're previous RTSS input latency tests (
http://forums.blurbusters.com/viewtopic ... 168#p16418), which also shows 1 frame of latency over uncapped, one reason why I was surprised by my results at first. You have any idea what is going on here?
Re: G-Sync 101 w/Chart (WIP)
Posted: 22 Jan 2017, 13:26
by Chief Blur Buster
Fascinating analysis of FPS limiter lag --
I'm not sure what is causing the RTSS differences; maybe you could contact him and try to get to the bottom of things -- maybe run a diff between your RTSS configurations (find out what settings are different). Also, another theory is different framerate limiters may produce dramatically different behaviours for specific games rather than others -- e.g. some logic difference in 1 game automatically causes only one or two specific framerate limiters to behave dramatically differently (adds 1 frame of lag). You both might want to try to track down the cause of the difference of your test results. Go into it with an open mind (maybe point him to this forum post), and think of what might be causing the differences.
Re: G-Sync 101 w/Chart (WIP)
Posted: 22 Jan 2017, 14:18
by jorimt
I notice his CS:GO numbers are a little high, and am wondering if he had "Multicore Rendering" enabled in the game settings, which can increase the input latency; I had it off.
RTSS limits the frames on the CPU side, so it's possible the aforementioned setting may have something to do with the difference. I'm definitely interested in finding out what is causing the inconsistency. Needless to say, I want to document the most accurate and correct information possible, no matter who's result end up being the right one.
I'll shoot him an email and update here if I find anything out.
Re: G-Sync 101 w/Chart (WIP)
Posted: 22 Jan 2017, 14:58
by Chief Blur Buster
Yes, the multicore setting might be causing the RTSS issue. You could do the test yourself -- enable/disable multicore while trying RTSS. I
It would not be the first time.... There are anecdotes of framerate limiters having weird lag quirks with certain games with certain configurations. Ask him if he's using a single or multi GPU setup, too.
-- Single versus multiple GPU (SLI)
-- Multicore rendering setting in Source Engines.
-- Minor variants of different VSYNC settings
Re: G-Sync 101 w/Chart (WIP)
Posted: 22 Jan 2017, 15:09
by jorimt
I already sent him an email, but Multicore Rendering is probably the culprit. I will do new tests with it on when I get the chance, and update here.
Re: G-Sync 101 w/Chart (WIP)
Posted: 22 Jan 2017, 15:42
by Sparky
The main thing to verify is that RTSS was actually limiting the framerate in the test scenario. As any framerate limit is only going to impact the latency if that limit is the thing that's bottlenecking the framerate.
As for exactly how RTSS works, I don't think it can prevent the game from grabbing user input and working on a frame, I think it just blocks the game from handing the frame off to the GPU. Easiest way to find out would be to ask the guy that developed the tool.
Re: G-Sync 101 w/Chart (WIP)
Posted: 22 Jan 2017, 16:12
by jorimt
Correct. In the scene I was testing (the same one for every scenario), I was pushing 300+ fps at all times before limiting, and the sheer number of scenarios that I tested with the same settings leads me to believe RTSS was indeed the framerate's limiting factor. I also had both the Afterburner overlay and my display's built-in fps/refresh readout enabled to verify the current fps during tests.
While I was surprised by my initial RTSS results, I assumed it was due to the fact that, unlike v-sync, G-Sync displays rendered frames as soon as they are ready, and it doesn't have to deal with even interval delivery like a fixed refresh display, thus no recurring/offset input delay experienced by v-sync when capped slightly below the max refresh. That, and in the exact same scenario, standalone v-sync + RTSS 142 fps limit was showing the expected results, with a 1 frame delay over the in-game cap.
That said, I still don't know how many samples Battle(non)sense took, or the complete specifics of his methods. Hopefully he'll email me back eventually.
Re: G-Sync 101 w/Chart (WIP)
Posted: 22 Jan 2017, 16:46
by Sparky
Not sure. I did see a one frame difference between RTSS and an in game cap with vsync off, but basically all the software I ran that test with is now outdated, and used an AMD graphics card with a CRT. Not exactly apples to apples comparison with your test setup.