Vsync has no effect on any backend

[JetSetter1984]

What happens?

When switching between vsync on or off, there is no difference at all.

What should happen?

With vsync off, there should be visible screen tearing but after extensive testing on different backends I have found the vsync option does nothing at all. I have a feeling this could be related to the stuttering people mentioned in issue #9736.

What hardware, operating system, and PPSSPP version? On desktop, GPU matters for graphical issues.

1080ti, ryzen 3600x, 16gb 3600mhz ddr4, Windows 10 pro

[hrydgard]

You haven't forced it on in the driver or something?

On Vulkan the "non-vsync" mode we use is mailbox, which is kind of like an in between but with no visible tearing lines.

[JetSetter1984]

Hey Henrik, thanks for the quick reply. No I have checked nvidia settings and made sure it was set to "use 3d application setting". I have tried it on every backend and the results are exactly the same. Vsync is not affecting anything at all. If you look at my 2nd from last post in issue #9736, before the response from mirh, it may provide an explanation. I'm no expert but I do know a fair bit. Really hope this issue is nailed soon.

[hrydgard]

Just to be sure, you are running the latest build from https://buildbot.orphis.net/ppsspp/ , right?

[JetSetter1984]

I was using build 1.9.3-324

[unknownbrackets]

The assumption that vsync off means tearing on is flawed. Vsync is a strategy to prevent tearing, but tearing is never guaranteed.

The Windows compositor may be preventing tearing. Timing may be preventing tearing. Tearing is not a desirable thing, and there are lots of ways to prevent it.

Vsync is just a strategy of waiting for the screen to update before submitting new data. It's about aligning timing to make tearing not happen (or at least be very rare.)

If you're just never seeing tearing either way, then great. Something else is preventing it.

As v1.9.3-324-g417796c67 is before #12659, we are not even trying to apply vsync in Vulkan or Direct3D 11. It should be expected for it to do nothing in those, because it was unsupported back then. Only OpenGL and Direct3D 9 even ask the driver to apply vsync in that old version.

So if you get no tearing in v1.9.3-324-g417796c67 using Direct3D 11, you can be confident that there's another reason tearing isn't happening. We definitely do not attempt vsync in that version and in that backend, regardless of settings.

In the latest git builds, all backends (except software rendering) request vsync from the driver when the setting is enabled.

-[Unknown]

[JetSetter1984]

Windows compositor or desktop composition only applies to windowed mode. Fullscreen there should be a clear difference. Even a stable 60fps with vsync off is easily noticeable, and would produce a far less smoother animation than vsync on. It will also definitely tear unless you had scanline syncing via rtss set to move the tear to the edge of the screen. It seems some form of synchronisation is active even when vsync is off, and it may be explained by my previous posts on issue #9736.

[unknownbrackets]

Nothing in that issue really explains anything.

If your problem is that you want tearing, I propose we close this issue. A setting to force tearing doesn't seem useful to PPSSPP.

If your problem is that you suspect #9736 is still an issue, then you'll be happy to know that the issue is not marked as closed. In that case, this issue should be closed as a duplicate. Any useful information that you believe isn't already in that issue should be contained there. It sounds like you're saying the useful information already exists there, though.

-[Unknown]

[JetSetter1984]

And how is ppsspp version 324 old, it was downloaded on the 29/02/2020,a few days ago

[JetSetter1984]

Sounds like you are avoiding the issue of vsync not working completely to me, and my post could definitely explain something if the emulator is behaving in that way.

[unknownbrackets]

Based on your comment in #9736, I already spent time adding vsync to all backends in #12659. No one is ignoring your comments. You're still using an old version without the fixes that were implemented based on your comments.

We do not explicitly use fullscreen exclusive in PPSSPP, and there's already a separate issue for that. I still think your compositor is forcing vsync.

I totally get that you feel you've found the secret to frame pacing issues, and you're annoyed that no one is jumping on this discovery with a whiz-bang fix. I'm sorry that my intelligence and problem solving skills have not met your expectations. Unfortunately, nothing about those comments has led me to any new or useful ideas in the code. I have already looked and not found a place where we would be incorrectly forcing vsync or other synchronization.

To say, I just do this for fun, and I'm losing interest in the frame pacing issues in general. I tried to look into them and fix some things, but I don't even experience them, so why should I actually care? And just pushing that information I've already looked at is definitely the key to the kingdom just tells me I'm not going to get any new information, so this is going nowhere.

Maybe someone else will come along and solve this. We've definitely had issues stay open for years and someone comes along and has a new idea and submits a fix.

Even so, I don't think this issue is separately useful. It sounds all tied into that original issue. If someone does come along - perhaps in 2022 - and gets inspired by your comments, it'll probably be within that other issue. Burying information in multiple issues just makes it less likely our hero will see them.

-[Unknown]

[JetSetter1984]

Not looking for a hero, just trying to help and add my thoughts. The comment, it works for me so why should I care is completely self-centered and I have a feeling not everyone on the PPSSPP team is that way inclined. I can confirm that vsync in the retroarch core works as intended, and switching it off causes tearing, as it should. This may explain why the retroarch core produces no such stutters, because their vsync implementation is working properly. This is why my comments in issue #9736 are relevant.

[iota97]

Tearing is a problem that MAY happen, VSync prevent it from happening.
VSync off doesn't imply tearing by itself.

Let's make an example:
An umbrella save you from getting wet, if you don't get wet with or without umbrella it just mean it's sunny, not that the umbrella is broken.

[JetSetter1984]

If you play anything on a display with a fixed refresh rate and do not apply vsync you will get tearing, guaranteed. Sorry, but there's no may about it, it will happen. It seems like the implementation of vsync in the standalone emulator is flawed, yet always on in some way regardless of the setting.

[JetSetter1984]

I just had a chance to check the latest 369 build, and in this release vsync on and off is working properly in opengl. With any backend in the newest release, vsync enabled eliminates all stuttering I have previously experienced, and gameplay is pretty much perfect, so amazing work there guys, good stuff. Vsync off is only truly off in opengl as this is the only backend where screen tearing will happen. All other backends are still syncing with the display in some way. I don't know what the main change was between build 324 and this one, but I believe the microstutter issue is completely fixed now by enabling vsync. Can anyone else confirm that the new build with vsync has fixed their stutters with 60fps titles?

[ghost]

@JetSetter1984 #12659

[ghost]

I dont know what are you talking about vsync is now working good and I stop getting micro stuttering.
Something is wrong with your PC lol.

[hrydgard]

I'm gonna close it, sounds like things are ok now.

[ghost]

At least he was right about micro stuttering being a vsync issue lol.

[JetSetter1984]

Just trying PPSSPP again this morning, I am still getting micro stutters but they are a single stutter and not prolonged as before, and far less frequent and noticeable. Perfect example is wipeout pulse, very small stutter every now and then. Best performance is DX11 by far.