Jittery/Stuttering graphics

pjft

@barbudreadmon said in Jittery/Stuttering graphics:

RA video sync stuff for any hardware-accelerated core, it has a tendency to screw performances, actually if you got vsync enabled for flycast it might be part of the performance issue

Oh my. I might - I actually use flycast for Naomi emulation, where it works awesome, but for Dreamcast I tend to stick to redream .

I'll see if I have vsync turned on, but I don't know what cores would have hardware acceleration.

@quicksilver we have mostly run MAME, FBNeo, Nestopia and Flycast around here, as far as RA cores go, in the last few months on the Pi4. I have had no meaningful issues with the setting on these, but will be on the lookout.

barbudreadmon

@pjft said in Jittery/Stuttering graphics:

I don't know what cores would have hardware acceleration

Any core that produce real 3D through the gpu.

pjft

@barbudreadmon Thanks for the clarification.

Educated guess then:

PCSX Rearmed
Yabasanshiro
Flycast
<the N64 ones>

Uneducated guesses or questions - for others who might know:

I believe MAME does everything on the CPU, even for 3D games, so that wouldn't be one.
Where does FB Neo stand in that regard?
Sega 32X cores? And is it at the core level, or would it be per-game (meaning, would 2D games not be affected)?

Sorry - video pipelines are not my expertise.

barbudreadmon

@pjft said in Jittery/Stuttering graphics:

PCSX Rearmed

Nope, that one is software-rendered. FBNeo, MAME and picodrive (32X core) too.

Quackwalks

@quicksilver I'm trying to find what I need to type in my retroarch.cfg to enable gsync but can't find anything. Could you help? Also, how do you Eggheads figure out exactly what needs to be typed?

pjft

@Quackwalks it should be

vrr_runloop_enable = "true"

if I recall correctly. I ended up reading the code on GitHub and digging into it from the initial commit.

Quackwalks

@pjft Thank you.

Clyde

@pjft said in Jittery/Stuttering graphics:

EDIT: and to be clear, my monitor is also not GSync compatible,

I think I found the solution for this "riddle". The option isn't actually only GSync, but at least GSync and FreeSync (and maybe other similar techniques? Are there any more?)

According to this comment from a contributor to an RA issue, "Sync exact framerate only works with g-sync/freesync displays." The Emulation General Wiki also sounds like, while MAME and RA do "make use of this functionality", they only do so on compatible monitors.

So the question is, does anyone who experiences an improvement by this option has a screen with such a functionality he/she don't know about, or does this option actually do more than its describtions says, or is it just an confirmation bias / placebo effect?

That said, the corresponding config line vrr_runloop_enable doesn't sound anything like the option in the RGUI/XMB or its description. Does anyone know what a "VRR Runloop" actually is?

Sorry for the subsidiary topic, but I think it may be helpful for understanding which options may (or actually can) help against tearing or stuttering and if so, in which circumstances.

dankcushions

the pi models do not support g sync/free sync.

quicksilver

@Clyde said in Jittery/Stuttering graphics:

@pjft said in Jittery/Stuttering graphics:

EDIT: and to be clear, my monitor is also not GSync compatible,

I think I found the solution for this "riddle". The option isn't actually only GSync, but at least GSync and FreeSync (and maybe other similar techniques? Are there any more?)

According to this comment from a contributor to an RA issue, "Sync exact framerate only works with g-sync/freesync displays." The Emulation General Wiki also sounds like, while MAME and RA do "make use of this functionality", they only do so on compatible monitors.

So the question is, does anyone who experiences an improvement by this option has a screen with such a functionality he/she don't know about, or does this option actually do more than its describtions says, or is it just an confirmation bias / placebo effect?

That said, the corresponding config line vrr_runloop_enable doesn't sound anything like the option in the RGUI/XMB or its description. Does anyone know what a "VRR Runloop" actually is?

Sorry for the subsidiary topic, but I think it may be helpful for understanding which options may (or actually can) help against tearing or stuttering and if so, in which circumstances.

My tv 100% does not have free/g sync capabilities. I have a Vizio TV and it was not introduced as a feature on Vizio TVs until a year after I got my tv. I can confirm that vrr_runloop_enable does turn on/off the setting in question. You can enable it in the retroarch core options config and then when in game check the retroarch menu and you'll see the setting has been enabled. Before redream was added as an optional emulator I was using flycast and the screen tearing/jitter issue was so prevalent
on the pi 4 that it made me almost stop using that core altogether. However I found that by enabling that setting it was no longer a problem. If you look back through the "working dreamcast games" thread you can see my previous discussion about it. I'd gladly provide my tv model/specs and a video of before and after it would help convince anyone.

pjft

@Clyde Info on the option:

https://github.com/libretro/RetroArch/pull/7019 and https://github.com/libretro/RetroArch/pull/7042

Quackwalks

Gsync enabled has solved the issue. I was wrong to say it doesn't happen in lr-fbneo because I started testing Samurai Showdown with and without it. I was able to switch it back and fourth and see that it was clearly having an impact. I played SFA2 again for mame for quite a while without any problems. There's some audio crackling and slowdown for lr-mupen64plus-next, which I never saw the problem occur in anyway, and in my few minutes with lr-pcsx-rearmed and lr-flycast I didn't notice any audio crackle or slowdown.

I'm glad I came here to ask. It's hard to believe there aren't more people bothered by the stuttering. That kind of stuff can drive me crazy. I hope you all can figure out all the beeps and boops. I'm gonna donate and play some crap now.

pjft

@Quackwalks Great to hear. Have fun and enjoy!

Yobiwan

I've got the exact same issue with ES in general. V-sync simply doesn't work. Video previews suffer from tearing too.
"Sync exact framerate" option in retroarch enables synchronization BUT it slows down framerate. Last update of Redream with vsync enabled gives me screen tearing and stuttering too (sonic adventure).
My desktop Pi4 with Raspbian had the same issue, vsync didn't work at all. I had to install Compton and enable vsync in config file in order to have a smooth experience.
But in retropie it seems a little bit different. Installing compton in pixel desktop interface via the terminal makes some weird stuff like black screens and vsync is still off. I'm not a linux specialist so I don't know what to do next to have a decent framerate with vsync in Retropie...
I've tested 2 different monitors : a 4K Samsung Smart TV and a 1440p G-sync 144hz PC monitor. Screen tearing everywhere, or low framerate... Exact same scenario in each case.
Kernel 5.4 doesn't help either.

BuZz

@Yobiwan are you running retropie from the Pixel Desktop?

Clyde

@dankcushions said in Jittery/Stuttering graphics:

the pi models do not support g sync/free sync.

I suspected as much. But what does that option that's clearly described as only working with GSync/FreeSync in the RGUI/XMB and the web? Are all the people who report that it helped them (presumely on a Pi) imagining things, or is the description wrong/incomplete?

@pjft said in Jittery/Stuttering graphics:

@Clyde Info on the option:

https://github.com/libretro/RetroArch/pull/7019 and https://github.com/libretro/RetroArch/pull/7042

Thanks, but both issues also only seem to address Variable Refresh Rate (VRR) on G-Sync compatible monitors as far as I understand.

That said, there was a similar discussion about this option in the FB Neo thread, beginning with this post, and followed by an interesting exchange between (mainly) @Riverstorm and @barbudreadmon.

Combining that with our discussion here brings me to the conclusion that this option really does something (undocumented?) even without the proper VRR hardware.

dankcushions

@Clyde i believe the option will disable retroarch's audio visual skew, which speeds up/slows down games to match your refresh rate, within tolerance. eg, SNES games which are something like 60.08hz, will be slowed down (imperceptibly) to to 60hz (assuming you're running at a 60hz mode), rather than you seeing a judder every so often. VRR mode may have other effects, but that particular one can be achieved by lowering/zero-ing the skew tolerance, so just do that, rather than leverage what IMO is a bug with the VRR setting. however it may have other effects.

obviously the setting should do nothing/be disabled on non-VRR hardware, but when i looked into it i believe it was hard to interrogate to see if a driver has VRR support since there are several frameworks, so i lost interest.

Yobiwan

@BuZz No, retropie boots directly. I managed to get rid of tearing by enabling kms in config.txt. It looks great ! But I've got some sounds issue and crashes when scrolling titles. I will try to reinstall Retropie from the beginning and activate the kms driver before adding roms and configuring everything else.

Brunnis

@Yobiwan said in Jittery/Stuttering graphics:

@BuZz No, retropie boots directly. I managed to get rid of tearing by enabling kms in config.txt. It looks great ! But I've got some sounds issue and crashes when scrolling titles. I will try to reinstall Retropie from the beginning and activate the kms driver before adding roms and configuring everything else.

Just to confirm: You're using full KMS (vc4-kms-v3d) instead of fake KMS (vc4-fkms-v3d)? My experience is that Linux kernel 5.4 + vc4-kms-v3d removes any traces of tearing, but I haven't investigated if it was kernel 5.4 itself that did something or if it was the switch to full KMS. My assumption has been that it was the full KMS driver.

I'd recommend anyone having issues with the default config to try full KMS to see if it improves things. It's not ready for release and lacks some features of the fake KMS driver, but it might still be worth trying it out.

Yobiwan

@Brunnis Yes, full KMS. I was using a custom image from the Supreme team (wolfanoz 256GB). Really impressive work, but I haven't found any solution to make KMS work correctly. I rebuilt an entire new image from official retropie 4.6 and it works amazingly well. I've spent a lot of time to configure all kind of stuff, and no more tearing. I don't know what this team has done but it was unplayable here.