Page 1 of 1

Loosing my mind with G-Sync & RetroArch stutter

PostPosted: 20 Feb 2018, 05:44
by BlackGuyRX
I've got the latest RA stable and i'm trying everything I can to get smooth scrolling and i'm at my wit's end. For the longest time, I've been told to disable vsync in addition to other settings like disable audio sync, disable audio rate control, adjust video refresh rate to match my monitor (either at 144hz or 120hz) and no matter what I do, it doesn't seem to fully cooperate. I usually end up noticing some minor scrolling stutter and it's driving me bonkers.

Now i'm being told I should enable vsync for G-Sync to even work properly with RA on top of setting frame throttle to 1 but that barely helps and I still notice the slight stutter. What am I doing wrong? My monitor is a AOC G2460PG and i'm on Windows 10.

Was also suggested to read this thread but i'm not sure how much it's helping me for RA so far

Re: Loosing my mind with G-Sync & RetroArch stutter

PostPosted: 20 Feb 2018, 11:45
by Chief Blur Buster
It's tough to diagnose these cases, but:
For emulator use, you ideally need the following:

(1) An emulator with excellent frame pacing;
(2) Emulator should have the ability to throttle the frame rate to sub-millisecond accuracy.
(3) For VRR drivers, VSYNC OFF versus VSYNC ON should not have to matter since you won't hit your GSYNC maximum.
(4) Emulator software should be configured as VSYNC OFF because there's no concept of "waiting for vsync" -- and should instead aim to very accurately framepace to avoid microstutter on a VRR display. 8-bit games were not designed VRR so framepacing problems still show microstutter problems even despite VRR's attempt to help. So framepacing ideally should be impeccable for VRR to benefit emulators with the latency-reducing benefits of VRR without adding microstutter.

One alternative workaround techique is to let the emulator run unthrottled (let emulator run as fast as possible), and then use RivaTuner/RTSS to cap the emulator frame rate to 60 (NTSC) or 50 (PAL). That intentionally slows down the emulator to realtime operation, and the frame pacing is fixed because RTSS has excellent frame pacing, and the stutter is fixed on VRR.

This technique does not work with all emulators but may be an additional option for compatible emulators. RTSS often has more accurate frame pacing capability than the frame-cappers built into emulators. However, RTSS may add more lag than the emulator's framerate throttle. So it's better for the emulator author to properly program RTSS precision into their emulator. If your microstutter disappears when using RTSS, then the emulator's framepacing is at fault, and the emulator developers can do better. If your RTSS test suceeds in the fix, then submit a bug report (BugZilla at the RetroArch site, linking to this post.

Decision matrix:
-- First, try the recommendations in Issue #1633 at RetroArch's bug tracker.
If this suceeds, then you're finished, the emulator frame pacing issue is fixed.
-- Failing that, try removing your framerate throttle, and use RTSS to throttle your emulator.
If this succeeds, then the emulator's frame pacing is confirmed defective, and the emulator authors should read the below paragraph.

Skip this paragraph if you don't know how to develop software.
NOTE: This is for other creators who visits Blur Busters Forums -- including emulator programmers / app developers / authors, please pay attention to your emulator's framepacing issues -- you want sub-millisecond timing accuracy in executing pageflips such as Direct3D Present() calls and such to avoid microstutters on VRR displays. A 1ms error in framepacing accuracy means a 1-screenwidth-per-second space shooter scroller or Super Mario scroller, will end up having a 1/1000 screenwidth microstutter (equivalent to 2 pixelwidths on a 1920x1080 display). This type of microstutter from 1ms framepacing error is noticeable when framepacing errors happens at regular intervals. For proper fluidity on VRR displays, your refresh cycles is controlled by the exact timing of the pageflip. So.....when you're in VSYNC OFF mode or VRR mode please use microsecond clocks for timing your framebuffer flips in your emulator source code!. This will reduce microstutter issues for software-triggered display refresh cycles (which is what GSYNC and FreeSync essentially is) especially for strongly fixed-Hz content such as videos and emulators. Basically when programming for a VRR display, you're now doing the equivalent of software-based VSYNC ON that's lower lag than waiting for a monitor's next fixed refresh cycle (for a non-VRR display). To successfully display fixed-Hz material (emulators, videos, etc) in a way that is as microstutter-free as true VSYNC ON, but without lag of VSYNC ON, you have to have really pristine framepacing accuracy. Do not use uncompensated millisecond-accurate timers, you may have to intentionally do a micro-busywait loop (a few tens or hundreds microseconds) within your timer event, to intentionally re-align your next frame buffer pageflip to a more exact interval since the last framebuffer flip (record a microsecond timestamp everytime you do a framebuffer flip, and align the next framebuffer flip as exactly as your software allows you to -- timer events add microstutter for fixed-Hz material on VRR displays, so pad the beginning of your timer event routine with a micro-busywait since last event, if you're using a timer event). RTSS does this sort of pageflip accuracy magic already. It's not rocket science. You might be using another method. But if you're using a timer event as your framepacing method....Then trigger your timer event approximately 1ms early and do a micro-busywait to microsecond accuracy. Timer jitter gone. No more microstutter. Problem solved. PC games don't have to worry about this as much as their framerates are designed to fluctuate, but emulators & videos are not designed to, so you have to improve your framepacing programming game, to the microseconds level in your own app/software that you create.


Re: Loosing my mind with G-Sync & RetroArch stutter

PostPosted: 20 Feb 2018, 16:04
by Chief Blur Buster
I have posted a follow up to the GSYNC bug report for the RetroArch issue tracker.

My comments to RetroArch's authors

It appears it's getting upvotes already.

Re: Loosing my mind with G-Sync & RetroArch stutter

PostPosted: 23 Feb 2018, 18:28
by wenarlin
im using retroarch, and it is going fine
You need to "audio sync on" - this is the main, and the only stable framethrottling method
You also need to run "high perfomance" profile in windows power options
You need to configure you audio interface like this Image - this need for audio sync - to work properly

Finally here is my RA config file:
just edit it, and enter correct refresh rate for you monitor (my is 165hz)
again: The main options for G-sync setup is:
audio sync=on
hard GPU sync=on
hard GPU sync frames=0
max swapchain images=1 (this is for minimum input lag)
threated video: off (this is for minimum input lag)
Do not use "frame throttle" - it is cause huge stutter !

Sorry for my english - im from russia :D
good luck! retroarch with g-sync - it is a real mind blowing expirience - this is like gaming on real console with CRT TV

Re: Loosing my mind with G-Sync & RetroArch stutter

PostPosted: 23 Feb 2018, 23:37
by Chief Blur Buster
Great, thank you for providing your suggestions!

Hopefully this fixes the OP's stutter issue!

Re: Loosing my mind with G-Sync & RetroArch stutter

PostPosted: 24 Feb 2018, 01:35
by lossofmercy
It's interesting. I figured most emulators could just hard cap things to 60 NTSC/50 PAL. But then there are arcade boards have a 'SYNC' cable that drives the refresh of the screen and run on a weird rate. Quite similar to G-Sync.

Re: Loosing my mind with G-Sync & RetroArch stutter

PostPosted: 20 Dec 2018, 22:15
by wenarlin
Finally they got g-sync support in retroarch

Re: Loosing my mind with G-Sync & RetroArch stutter

PostPosted: 20 Dec 2018, 22:41
by RealNC
wenarlin wrote:Finally they got g-sync support in retroarch



Re: Loosing my mind with G-Sync & RetroArch stutter

PostPosted: 28 Dec 2018, 17:49
by Chief Blur Buster


That's the Proper Way to do it. Present the frame at the exact original timing and let the monitor sync to that.

Mind you, the emulator cores need to preserve original frame timings, but fortunately most emulator cores seem to be able to do it (with some core-specific tweaks -- e.g. MAME needs "Enable Throttle")