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
viewtopic.php?f=5&t=3073
Loosing my mind with G-Sync & RetroArch stutter
- Chief Blur Buster
- Site Admin
- Posts: 11653
- Joined: 05 Dec 2013, 15:44
- Location: Toronto / Hamilton, Ontario, Canada
- Contact:
Re: Loosing my mind with G-Sync & RetroArch stutter
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.
<FOR SOFTWARE DEVELOPERS>
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.
</FOR SOFTWARE DEVELOPERS>
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.
<FOR SOFTWARE DEVELOPERS>
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.
</FOR SOFTWARE DEVELOPERS>
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter
![Image](https://blurbusters.com/wp-content/uploads/2024/01/BlurBustersCollectionBanner-750x80.png)
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: Loosing my mind with G-Sync & RetroArch stutter
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.
My comments to RetroArch's authors
It appears it's getting upvotes already.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter
![Image](https://blurbusters.com/wp-content/uploads/2024/01/BlurBustersCollectionBanner-750x80.png)
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!
Re: Loosing my mind with G-Sync & RetroArch stutter
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
- this need for audio sync - to work properly
Finally here is my RA config file:
http://puu.sh/zuhJi/64f2fd81d9.zip
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
v-sync=off
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 Russla
good luck! retroarch with g-sync - it is a real mind blowing expirience - this is like gaming on real console with CRT TV
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](http://puu.sh/zuhBS/d94d1cd53e.png)
Finally here is my RA config file:
http://puu.sh/zuhJi/64f2fd81d9.zip
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
v-sync=off
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 Russla
![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
good luck! retroarch with g-sync - it is a real mind blowing expirience - this is like gaming on real console with CRT TV
pg279q, 4790k, asus m7h, gtx970, 16gb RAM, asus xonar DGX
- Chief Blur Buster
- Site Admin
- Posts: 11653
- Joined: 05 Dec 2013, 15:44
- Location: Toronto / Hamilton, Ontario, Canada
- Contact:
Re: Loosing my mind with G-Sync & RetroArch stutter
Great, thank you for providing your suggestions!
Hopefully this fixes the OP's stutter issue!
Hopefully this fixes the OP's stutter issue!
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter
![Image](https://blurbusters.com/wp-content/uploads/2024/01/BlurBustersCollectionBanner-750x80.png)
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!
-
- Posts: 76
- Joined: 06 Feb 2018, 18:00
Re: Loosing my mind with G-Sync & RetroArch stutter
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
Finally they got g-sync support in retroarch
https://www.libretro.com/index.php/category/g-sync/
https://www.libretro.com/index.php/category/g-sync/
pg279q, 4790k, asus m7h, gtx970, 16gb RAM, asus xonar DGX
Re: Loosing my mind with G-Sync & RetroArch stutter
wenarlin wrote:Finally they got g-sync support in retroarch
https://www.libretro.com/index.php/category/g-sync/
![Image](https://i.imgur.com/y8s30Qx.gif)
![Mr. Green :mrgreen:](./images/smilies/icon_mrgreen.gif)
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: Loosing my mind with G-Sync & RetroArch stutter
Yup.
![Image](https://www.libretro.com/wp-content/uploads/2018/08/sync-to-exact-content-framerate-768x603.png)
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")
![Image](https://www.libretro.com/wp-content/uploads/2018/08/sync-to-exact-content-framerate-768x603.png)
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")
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter
![Image](https://blurbusters.com/wp-content/uploads/2024/01/BlurBustersCollectionBanner-750x80.png)
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!