Recently noticed frame pacing issues when using VRR in Retroarch

The ultra fast flicker

it will flicker like this on non-VRR displays (1:19 mark), though this could also be due to recording software issues. It should be double speed really. So this is incorrect.

but result would be closer to this. Mobile phone records at 60 hz and it does not display even ultra flicker but monitor does.

It also works via Switchres on a CRT VGA in 120 hz mode

Depends also on the emulator. On windowed mode it flickers slower on all emulators, as Ares and Snes9x require fullscreen. Retroarch supports windowed VRR too. If you try the game on Finalburn for example,it flickers slow in fullscreen too as emulator has not implemented VRR yet.

On Mesen you have to enable exclusive full screen mode for it to work.

I’m a little confused tbh :sweat_smile:

I can’t tell the way it flickers on your second video. Is the first video supposed to be slower than the real SNES?

I tested with Ares in Fullscreen btw.

yes, the first video is slower. you are not supposed to spot the color switch between white and purple. Though somet It is similar to the character flicker shadow in Samurai Showdown 2, though there at least you have the character select screen background animation smoothness to see if vrr is active.

now I noticed. First video sometimes does flicker slower and it confused me. I guess YouTube player synchro plays games too.

found a better video that is older and there it flickers slower regardless. Eg at 3.00m.

https://youtu.be/UClnK8_ZJ_k

That last video you posted is 30fps. It cannot display a rapid effect like that properly. Also, you must mean yellow and purple, not white.

You say you are not supposed to see the flicker, are you sure about that? Can you confirm the effect on a real SNES and CRT? I had the game back in the day but i can’t remember. But why would they make a flicker effect in the first place if you couldn’t see it?

The game runs natively at 60fps, i assume half of them is yellow and other half is purple. That’s fast but it should also be very noticeable to the human eye. If you can’t see it then something must be wrong.

If it doesn’t supposed to flicker in a noticeably manner, then every emulator on every screen i personally tried displays is wrong. Not just RetroArch.

Ok i also did another test to make sure the effect is correct in RetroArch:

Just press “P” and then tap “K” to advance one frame. Every time you tap “K” once, you should see a different color. 1 frame yellow, 1 frame purple. This is the correct effect and that’s what i’m getting in RetroArch using “sync to content” on a 240hz VRR display. It’s a perfect 1 color change every frame.

Edit: Hmmm, the frame advance method might not be a reliable way to see this because even if i turn sync to content OFF and i can clearly see the uneven flickering, the frame advance still shows the same result. So the bad sync only happens when the game is actually running and is not paused (in my case).

But it still confirms that it’s 30 frames one color and 30 frames the other. Which should be very noticeable to the eye on the real SNES too.

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.

1 Like

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.

1 Like

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

1 Like

@vanfanel, @GemaH, @petran791

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.

1 Like

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.

1 Like

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.

2 Likes

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.