Yes, pretty much same test you just did with the in-game limiter, but this time with RTSS.jorimt wrote:Ah, then I'd have to test the in-game limiter up against RTSS with an upper 120 something FPS limit in the 150% resolution scenario where I can only sustain framerates in the 130s?
If so, I could do two more quick runs for confirmation.
Blur Buster's G-SYNC 101 Series Discussion
Re: Blur Buster's G-SYNC 101 Series Discussion
Steam • GitHub • Stack Overflow
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.
Re: Blur Buster's G-SYNC 101 Series Discussion
But the in-game limiter scenario was 100% res with 141 FPS limit. The 130s uncapped/sustain framerate scenario was 150% res.
So testing RTSS against the in-game limiter in that scenario would give me the same numbers/differences in the chart I embedded in my other post.
I'm assuming I'd need to test both the in-game limiter and RTSS again with the 150% res scenario so that the in-game limiter doesn't have a lot of excess frames (low frametimes) to work with...
So testing RTSS against the in-game limiter in that scenario would give me the same numbers/differences in the chart I embedded in my other post.
I'm assuming I'd need to test both the in-game limiter and RTSS again with the 150% res scenario so that the in-game limiter doesn't have a lot of excess frames (low frametimes) to work with...
(jorimt: /jor-uhm-tee/)
Author: Blur Busters "G-SYNC 101" Series
Displays: ASUS PG27AQN, LG 48CX VR: Beyond, Quest 3, Reverb G2, Index OS: Windows 11 Pro Case: Fractal Design Torrent PSU: Seasonic PRIME TX-1000 MB: ASUS Z790 Hero CPU: Intel i9-13900k w/Noctua NH-U12A GPU: GIGABYTE RTX 4090 GAMING OC RAM: 32GB G.SKILL Trident Z5 DDR5 6400MHz CL32 SSDs: 2TB WD_BLACK SN850 (OS), 4TB WD_BLACK SN850X (Games) Keyboards: Wooting 60HE, Logitech G915 TKL Mice: Razer Viper Mini SE, Razer Viper 8kHz Sound: Creative Sound Blaster Katana V2 (speakers/amp/DAC), AFUL Performer 8 (IEMs)
Author: Blur Busters "G-SYNC 101" Series
Displays: ASUS PG27AQN, LG 48CX VR: Beyond, Quest 3, Reverb G2, Index OS: Windows 11 Pro Case: Fractal Design Torrent PSU: Seasonic PRIME TX-1000 MB: ASUS Z790 Hero CPU: Intel i9-13900k w/Noctua NH-U12A GPU: GIGABYTE RTX 4090 GAMING OC RAM: 32GB G.SKILL Trident Z5 DDR5 6400MHz CL32 SSDs: 2TB WD_BLACK SN850 (OS), 4TB WD_BLACK SN850X (Games) Keyboards: Wooting 60HE, Logitech G915 TKL Mice: Razer Viper Mini SE, Razer Viper 8kHz Sound: Creative Sound Blaster Katana V2 (speakers/amp/DAC), AFUL Performer 8 (IEMs)
Re: Blur Buster's G-SYNC 101 Series Discussion
Oh wait, I've misread your post I thought you used 150% resolution for both capped and uncapped...
That's unfortunate. That means the results don't actually tell us the latency difference between capped and uncapped at nearly idenitcal frame rates.
The theory was that uncapped ~130FPS vs capped 130FPS would show no big latency difference in OW, but would show one in other games that don't have the latency-improving settings and tweaks OW has.
That's unfortunate. That means the results don't actually tell us the latency difference between capped and uncapped at nearly idenitcal frame rates.
The theory was that uncapped ~130FPS vs capped 130FPS would show no big latency difference in OW, but would show one in other games that don't have the latency-improving settings and tweaks OW has.
Steam • GitHub • Stack Overflow
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.
Re: Blur Buster's G-SYNC 101 Series Discussion
You can see now why I didn't want to deal with this specific behavior during my G-SYNC tests; it a convoluted, variable mess
I will retest the 150% in-game limiter and RTSS limiter scenarios with sustained framerates in the 130s, but capped to 120s, and post the results.
I will retest the 150% in-game limiter and RTSS limiter scenarios with sustained framerates in the 130s, but capped to 120s, and post the results.
(jorimt: /jor-uhm-tee/)
Author: Blur Busters "G-SYNC 101" Series
Displays: ASUS PG27AQN, LG 48CX VR: Beyond, Quest 3, Reverb G2, Index OS: Windows 11 Pro Case: Fractal Design Torrent PSU: Seasonic PRIME TX-1000 MB: ASUS Z790 Hero CPU: Intel i9-13900k w/Noctua NH-U12A GPU: GIGABYTE RTX 4090 GAMING OC RAM: 32GB G.SKILL Trident Z5 DDR5 6400MHz CL32 SSDs: 2TB WD_BLACK SN850 (OS), 4TB WD_BLACK SN850X (Games) Keyboards: Wooting 60HE, Logitech G915 TKL Mice: Razer Viper Mini SE, Razer Viper 8kHz Sound: Creative Sound Blaster Katana V2 (speakers/amp/DAC), AFUL Performer 8 (IEMs)
Author: Blur Busters "G-SYNC 101" Series
Displays: ASUS PG27AQN, LG 48CX VR: Beyond, Quest 3, Reverb G2, Index OS: Windows 11 Pro Case: Fractal Design Torrent PSU: Seasonic PRIME TX-1000 MB: ASUS Z790 Hero CPU: Intel i9-13900k w/Noctua NH-U12A GPU: GIGABYTE RTX 4090 GAMING OC RAM: 32GB G.SKILL Trident Z5 DDR5 6400MHz CL32 SSDs: 2TB WD_BLACK SN850 (OS), 4TB WD_BLACK SN850X (Games) Keyboards: Wooting 60HE, Logitech G915 TKL Mice: Razer Viper Mini SE, Razer Viper 8kHz Sound: Creative Sound Blaster Katana V2 (speakers/amp/DAC), AFUL Performer 8 (IEMs)
Re: Blur Buster's G-SYNC 101 Series Discussion
Okay, the results are in...
150% internal res was set, which allowed the test scene to hover in the mid to high 130s, with a 135 average. I set both the in-game and RTSS FPS limiter to 130, and tested them each.
The first result below is the previous uncapped test to compare the new tests with as a baseline. I did not test MPRF default/1 this time, as we've already established it makes no difference in this game.
G-SYNC + V-SYNC + mid to high 130s Uncapped + MPRF Default:
MIN: 35
AVG: 38
MAX: 41
G-SYNC + V-SYNC + 130 FPS In-game FPS Limit + MPRF Default:
MIN: 23
AVG: 28
MAX: 33
G-SYNC + V-SYNC + 130 FPS RTSS FPS Limit + MPRF Default:
MIN: 30
AVG: 33
MAX: 40
So in-game appears to have a 1-2 frame reduction (little over 1 1/2 frame average) compared to uncapped at the same framerate, and RTSS 0-1 frame reduction (nearly 1 frame average).
I'm certain this can vary depending on the given game, system, and sustained framerate at any given point.
It looks like from these tests, much like Fast Sync's third buffer utilizes the excess frames to reduce input latency/delivery time, good in-game limiters do the same thing, just at an earlier point in the input latency chain. Thus an optimal G-SYNC setup in any game would be to have frames above/well above the refresh rate, and cap 3 FPS below the refresh rate with an in-game limiter.
150% internal res was set, which allowed the test scene to hover in the mid to high 130s, with a 135 average. I set both the in-game and RTSS FPS limiter to 130, and tested them each.
The first result below is the previous uncapped test to compare the new tests with as a baseline. I did not test MPRF default/1 this time, as we've already established it makes no difference in this game.
G-SYNC + V-SYNC + mid to high 130s Uncapped + MPRF Default:
MIN: 35
AVG: 38
MAX: 41
G-SYNC + V-SYNC + 130 FPS In-game FPS Limit + MPRF Default:
MIN: 23
AVG: 28
MAX: 33
G-SYNC + V-SYNC + 130 FPS RTSS FPS Limit + MPRF Default:
MIN: 30
AVG: 33
MAX: 40
So in-game appears to have a 1-2 frame reduction (little over 1 1/2 frame average) compared to uncapped at the same framerate, and RTSS 0-1 frame reduction (nearly 1 frame average).
I'm certain this can vary depending on the given game, system, and sustained framerate at any given point.
It looks like from these tests, much like Fast Sync's third buffer utilizes the excess frames to reduce input latency/delivery time, good in-game limiters do the same thing, just at an earlier point in the input latency chain. Thus an optimal G-SYNC setup in any game would be to have frames above/well above the refresh rate, and cap 3 FPS below the refresh rate with an in-game limiter.
(jorimt: /jor-uhm-tee/)
Author: Blur Busters "G-SYNC 101" Series
Displays: ASUS PG27AQN, LG 48CX VR: Beyond, Quest 3, Reverb G2, Index OS: Windows 11 Pro Case: Fractal Design Torrent PSU: Seasonic PRIME TX-1000 MB: ASUS Z790 Hero CPU: Intel i9-13900k w/Noctua NH-U12A GPU: GIGABYTE RTX 4090 GAMING OC RAM: 32GB G.SKILL Trident Z5 DDR5 6400MHz CL32 SSDs: 2TB WD_BLACK SN850 (OS), 4TB WD_BLACK SN850X (Games) Keyboards: Wooting 60HE, Logitech G915 TKL Mice: Razer Viper Mini SE, Razer Viper 8kHz Sound: Creative Sound Blaster Katana V2 (speakers/amp/DAC), AFUL Performer 8 (IEMs)
Author: Blur Busters "G-SYNC 101" Series
Displays: ASUS PG27AQN, LG 48CX VR: Beyond, Quest 3, Reverb G2, Index OS: Windows 11 Pro Case: Fractal Design Torrent PSU: Seasonic PRIME TX-1000 MB: ASUS Z790 Hero CPU: Intel i9-13900k w/Noctua NH-U12A GPU: GIGABYTE RTX 4090 GAMING OC RAM: 32GB G.SKILL Trident Z5 DDR5 6400MHz CL32 SSDs: 2TB WD_BLACK SN850 (OS), 4TB WD_BLACK SN850X (Games) Keyboards: Wooting 60HE, Logitech G915 TKL Mice: Razer Viper Mini SE, Razer Viper 8kHz Sound: Creative Sound Blaster Katana V2 (speakers/amp/DAC), AFUL Performer 8 (IEMs)
Re: Blur Buster's G-SYNC 101 Series Discussion
Awesome! Thanks for doing these. The in-game limiter still wins. I suspected the in-game limiter would get closer and closer to RTSS in this scenario, but that clearly isn't the case. It still pulls out a latency reduction out of (seemingly) thin air. No idea why in this case
I hope this makes the RTSS author consider adding the "constant throttling" option in the future. When FPS starts getting low, that's exactly when you want to reduce latency. High FPS, even uncapped is fine due to low frame times. Once your FPS gets low, you'd want a frame cap even more there than you do in high FPS situations...
I hope this makes the RTSS author consider adding the "constant throttling" option in the future. When FPS starts getting low, that's exactly when you want to reduce latency. High FPS, even uncapped is fine due to low frame times. Once your FPS gets low, you'd want a frame cap even more there than you do in high FPS situations...
Yep. This has been done in an open source Quake engine I think to implement 0-latency vsync. The game ran at 1000+FPS uncapped (even more; it's an old game), so the dev team utilized the <1ms render times to reduce vsync input lag to extremely low levels.jorimt wrote:It looks like from these tests, much like Fast Sync's third buffer utilizes the excess frames to reduce input latency/delivery time, good in-game limiters do the same thing, just at an earlier point in the input latency chain. Thus an optimal G-SYNC setup in any game would be to have frames above/well above the refresh rate, and cap 3 FPS below the refresh rate with an in-game limiter.
Steam • GitHub • Stack Overflow
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.
Re: Blur Buster's G-SYNC 101 Series Discussion
Glad to do them (it answers a few lingering questions of my own), and it validates your theory more than it doesn't.
As for MPRF, we can likely project the exact same scenarios as I last posted between uncapped/in-game/RTSS, but add or remove a couple of frames of delay across the board depending on the internal MPRF value of the given game.
As for MPRF, we can likely project the exact same scenarios as I last posted between uncapped/in-game/RTSS, but add or remove a couple of frames of delay across the board depending on the internal MPRF value of the given game.
(jorimt: /jor-uhm-tee/)
Author: Blur Busters "G-SYNC 101" Series
Displays: ASUS PG27AQN, LG 48CX VR: Beyond, Quest 3, Reverb G2, Index OS: Windows 11 Pro Case: Fractal Design Torrent PSU: Seasonic PRIME TX-1000 MB: ASUS Z790 Hero CPU: Intel i9-13900k w/Noctua NH-U12A GPU: GIGABYTE RTX 4090 GAMING OC RAM: 32GB G.SKILL Trident Z5 DDR5 6400MHz CL32 SSDs: 2TB WD_BLACK SN850 (OS), 4TB WD_BLACK SN850X (Games) Keyboards: Wooting 60HE, Logitech G915 TKL Mice: Razer Viper Mini SE, Razer Viper 8kHz Sound: Creative Sound Blaster Katana V2 (speakers/amp/DAC), AFUL Performer 8 (IEMs)
Author: Blur Busters "G-SYNC 101" Series
Displays: ASUS PG27AQN, LG 48CX VR: Beyond, Quest 3, Reverb G2, Index OS: Windows 11 Pro Case: Fractal Design Torrent PSU: Seasonic PRIME TX-1000 MB: ASUS Z790 Hero CPU: Intel i9-13900k w/Noctua NH-U12A GPU: GIGABYTE RTX 4090 GAMING OC RAM: 32GB G.SKILL Trident Z5 DDR5 6400MHz CL32 SSDs: 2TB WD_BLACK SN850 (OS), 4TB WD_BLACK SN850X (Games) Keyboards: Wooting 60HE, Logitech G915 TKL Mice: Razer Viper Mini SE, Razer Viper 8kHz Sound: Creative Sound Blaster Katana V2 (speakers/amp/DAC), AFUL Performer 8 (IEMs)
Re: Blur Buster's G-SYNC 101 Series Discussion
One last point:
An in-game limiter can know when a good render-start-time would be without actually having to render anything.
It should be noted that in-game limiters don't actually have to render the excess frames, unlike fast sync. With fast sync, it renders frames constantly; it brute-forces the issue to find out when the best render-start-time would be by actually trying as many render-start-times as possible, and the only way to do that is running the game with vsync off.jorimt wrote:It looks like from these tests, much like Fast Sync's third buffer utilizes the excess frames to reduce input latency/delivery time, good in-game limiters do the same thing, just at an earlier point in the input latency chain. Thus an optimal G-SYNC setup in any game would be to have frames above/well above the refresh rate, and cap 3 FPS below the refresh rate with an in-game limiter.
An in-game limiter can know when a good render-start-time would be without actually having to render anything.
Steam • GitHub • Stack Overflow
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.
- Chief Blur Buster
- Site Admin
- Posts: 11653
- Joined: 05 Dec 2013, 15:44
- Location: Toronto / Hamilton, Ontario, Canada
- Contact:
Re: Blur Buster's G-SYNC 101 Series Discussion
Take it easy on Jorim. We need him to create additional content!
Do you know how hard and laborious it is to analyze over 5000 different lag samples (frame-counting sessions in high speed video!) Every single time, frame-count between a LED flash & screen activity -- then rinse and repeat -- 5080 times.
The arrival of the first 240Hz monitor is a Blur Busters special moment, warranting such unusually intense testing that will not be repeated manually.
So take it easy. Pretty please.
Do you know how hard and laborious it is to analyze over 5000 different lag samples (frame-counting sessions in high speed video!) Every single time, frame-count between a LED flash & screen activity -- then rinse and repeat -- 5080 times.
The arrival of the first 240Hz monitor is a Blur Busters special moment, warranting such unusually intense testing that will not be repeated manually.
So take it easy. Pretty please.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter
Forum Rules wrote: 1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
2. Please report rule violations If you see a post that violates forum rules, then report the post.
3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!
- Chief Blur Buster
- Site Admin
- Posts: 11653
- Joined: 05 Dec 2013, 15:44
- Location: Toronto / Hamilton, Ontario, Canada
- Contact:
Re: Blur Buster's G-SYNC 101 Series Discussion
Yep. Good predictive just-in-time rendering can do that. And the programmer has to do a good job of doing predictive rendering properly.RealNC wrote:An in-game limiter can know when a good render-start-time would be without actually having to render anything.
That said, for non-VRR displays, there is an immense lag penalty for a missed VSYNC.
Fast Sync (ala "low lag triple buffering technique") avoids that risk at a great penalty (rendering huge numbers of never-displayed frames, "just in case") without needing the game to support any predictive just-in-time rendering.
Already said before, but in another 'related' perspective, capped GSYNC/FreeSync is very forgiving while being low lag -- early/late frames have the potential to be displayed immediately anyway. With enough headroom (e.g. 138fps at 144Hz) there's plenty of margin for frametimes to be early/late and there's practically never such a thing as a "too late to be on time for VSYNC". In other words, frame-capped VRR is almost the ideal "low-lag VSYNC ON" experience.
Various low-latency "VSYNC ON" options:
Predictive rendering: Works on all displays. Last minute just-in-time rendering. Efficient. But stutters if render times are mis-predicted
Fast Sync: Works on all displays. Inefficient. Microstutters from fps-vs-Hz mismatch. Less microstutter the higher framerate is.
Capped GSYNC/FreeSync: Requires said VRR display. Efficient. So far, the ultimate low-lag "VSYNC ON" experience. (If not using strobing)
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter
Forum Rules wrote: 1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
2. Please report rule violations If you see a post that violates forum rules, then report the post.
3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!