Of course frame sync issues like the one being discussed here are not noticeable when the emulation is paused and you advance frames manually. They are only noticeable with games running at fullspeed.
I assumed the frame advance feature would be able to capture the uneven frame rate (by showing repeated frames) but apparently it doesn’t.
But anyway, by disabling the sync to content option, i can clearly see the flickering being inconsistent and uneven. I can see some moments where one color sticks out more and the timing isn’t smooth. When i re-enable sync to content, it evens out and looks perfect.
that kind of slow flicker in the 30 fps video happens at 60 fps too when VRR or exclusive fullscreen is not enabled. but on Retroarch it happens also with sync content off. Have to disable gsync from Nvidia panel instead
Why have it off? You are supposed to have it ON in order for VRR to work.
I think i’m probably missing something you guys, i don’t think i’m on the same page as you.
What are your issues exactly?
if nvidia control panel has gsync activated for retroarch, it does not matter if " sync to exact content" option is activated or not. Gsync always activates on Retroarch as gsync indicator is shown. it is only disabled with setting it to " fixed refresh rate" in Nvidia panel. sync option is kinda redundant in this case
So the issue is that VRR on RetroArch doesn’t work when the sync option is OFF?
But it still works for you if it’s ON, right?
So there is no problem other than having an extra option in the RA list.
Also, what about freesync or non-G-sync monitors? Mine is not G-sync but i can enable it with the more recent drivers. Maybe in my case this option is needed?
you don’t want to have 2 competing sync models happening at the same time.
Either force your desired sync in the GPU control panel or set it to “let the application decide” and do it in RetroArch instead. Don’t try to do both at the same time.
Since my monitor is not a real G-Sync one, i don’t have that option in the GPU 3D settings control panel. I only have the general “set up g-sync” section where you select fullscreen and windowed applications.
Maybe you could disable the control panel option for RetroArch only and set the sync to content ON?
On Nvidia cpl you can only pick gsync or fixed refresh. The " let application decide" is not available. This on Windows.
On Linux if you disable the sync box in Retroarch, Gsync is disabled
Seems like you might have missed this post.
Recently noticed frame pacing issues when using VRR in Retroarch
It is imperative to use the Set Display Reported Refresh Rate option when using VRR/GSYNC/Sync To Content Refresh Rate.
At least that worked for me and I don’t have an official GSync certified monitor.
I don’t have any issue with VRR in RetroArch myself. Everything moves smoothly and evenly, at it should, on my 240hz monitor with “sync to content frame rate” ON.
And yes, refresh rate is set at 240hz in the main .cfg.
Hello Cyber. Sorry, yes, I had missed that post, it’s strange because I’m following this tread pretty closely, so thanks for pointing to it.
The “Set Display Reported Refresh Rate” option doesn’t do much here. I have activated it countless times when doing these experiments “just in case”, but rationally, it’s quite the opposite. The physical refresh rate known to RetroArch (“video_refresh_rate”) is used to adjust the refresh rate of the games to the host refrest rate when VSYNC is ON and “Sync to Exact” is OFF. But when “Sync to Exact” is ON, it’s quite the opposite: the display is supposed to sync to the emulated system refresh rate. So, in a nutshell, there is no rational reason to think that checking “Set Display Reported Refresh Rate” will fix the microstuttering we are seeing when “Sync to Exact” is ON.
The reason for that microstuttering is already known. Again: RetroArch should re-align each next frame buffer pageflip to a more exact interval since the last framebuffer flip.
Or, in other words: This issue is not about framerate, but about frame time (time bewteen pageflips). Frame times have to be constant, not variable. In emulation, you can have almost constant 59.94 FPS but frametimes can be varying constantly. They must not vary so much. That’s how this issue is avoided. That’s why it’s NOT so prominent in native games.
The original explanation was already given by the BlurBusters forum founder time ago. This is EXPECTED to happen.
I will watch this thread a bit longer (this issue has been brought over and over during the last years and was forgotten again and again) and in the end I think I will have to put my money where my mouth is and try to fix it myself, because comments about unrelated options and about proprietary/closed NGreedia stuff like GSync won’t help at all since we can NOT know how that thing works and “Sync to Exact” is supposed to work correctly with Freesync too.
@Tatsuya79 Your input on this would be greatly appreciated. I don’t know RetroArch refresh rate control stuff internally at all (I did some RA graphics backends years ago, but refresh rate is not controller from there) so, would it be possible to do an approximate “solution” in RetroArch by “forcing” the cores to request buffer swaps on a more “steady” cadence (possibly “micro-pausing” the cores to deceive them) or will it require per-core intervention?
It also matters to set Preferred Refresh rate to Application controlled instead of Max refresh rate, so that Retroarch is not influenced by Gsync framerate difference. Or else refresh in my case goes to 97 hz (Gsync 3 frame difference) instead of 100 hz.
I have no idea how to do what you request, I’m not sure I understand it at all sorry.
I’m not a programmer, just a self-taught beginner, I’m not going to touch anything unless I can test it directly.
Everything is working fine for me on my g-sync screen limited to 120hz and I can’t test above that.
Setting your monitor max refresh in RA is important as anything above that will be treated as vsync off.
I remember you posting this a while ago but I forgot about it and when I finally got my 100Hz setup up and running, frame rates were all over the place in RetroArch but all was resolved when I clicked on that Set Display Reported Refresh Rate.
So it is like the missing link in a number of VRR related frame rate issues.
If anything it should be made more obvious how important it is to click that if running VRR or at least a tip to try it having framerate issues after enabling Sync To Content Refresh Rate.
I have a Windows PC and have frame timing issues on certain cores.
A test for reproduction would be to run 240p Test Suite in PS1, drop shadow test, compare result of audio on vs off.
I have an update. I tried eliminating all possible variables by disabling audio and testing different settings one-by-one. I tried taking video but it didn’t work, even with a 240 fps capture… All drivers are set to use d3d12 video.
Mesen 240p test suite drop shadow: bad frame timing is fixed with VRR display, V-sync ON, and Sync to exact OFF.
Genesis Plus GX 240p Test Suite drop shadow: Frame timing is good regardless of Sync to exact setting. Vsync must be on.
Beetle PCE: Same as Genesis
bsnes-jg: Same as Mesen
Beetle PSX HW: Vsync must be ON, Vsync swap interval to 1 instead of Auto, Shader sub-frames OFF, and Sync to exact OFF
So whatever Sync to exact does is causing problems with my setup.
Turning audio back on creates some instability. It can kind of be corrected with high audio latency, but not always, but it’s much better having Sync to exact off even with the audio enabled.
What type of VRR monitor do you have? If you mentioned it already, I missed that post. Freesync, Freesync Premium, Gsync compatible, Gsync module equipped or HDMI 2.2 VRR?
It’s a television. It uses HDMI 2.1 VRR and is G-Sync compatible.
An update, while V-Sync on would give me the good frame pacing, it also distorted the framerate of the content (I didn’t really pay attention to this before). I’m not sure why. But I did figure out that turning V-Sync OFF and turning Sync to exact back to ON results in a perfect result: the framerate is correct and the frame timing is stable and gives me good flicker-based drop shadows. This happens with both D3D12 and Vulkan (I don’t care enough about the others to test, sorry).
So maybe there is something that causes V-Sync and Sync-to-exact to not play nicely with each other, at least on this Nvidia card + HDMI VRR combo.
Also there are a lot of synchronization options for reducing input lag. I do have to wonder if a number of them are obsolete or less relevant in the context of a high-frequency VRR display. Perhaps, if maintaining all these options is a burden, and with high-frequency VRR displays being common, it’s better to consider retiring some if they are causing issues. Just my 2¢.