[Libretro] [Vulkan] Buffer Graphics Commands should be disabled by default

[vanfanel]

What should happen

On the libretro core (I always build latest version from github) the default for Video->Buffer Graphics Commands is 2, which causes erratic framerate no matter what.

You can easily see this on fine-scrolling games (I can see it on 3D games too, but for most people it seems to be hard to see).
For example, look at the scrolling text in Ridge Racers menus: you can see it's perfectly smooth on a real PSP and in fact it's perfectly smooth on PPSSPP Video->Buffer Graphics Commands is set to No Buffer, but it's moving is jerky with the default value of 2.

So, please, make No Buffer the default. Even if buffering Vulkan commands can have some slight benefits on weak hardware, it doesn't compensate for breaking the games motion all around.

Who would this benefit

Everyone looking to reproduce the original smooth/continuous motion of many of the PSP games.
Since PPSSPP is an emulator, that should be a priority I believe.

Platform (if relevant)

libretro / Retroarch

Games this would be useful in

Any game will do: it's easier to see on fine-scrolling sequences.

Other emulators or software with a similar feature

No response

Checklist

• Check the latest git build in case it's already implemented.
• Search for other requests of the same feature.

[hrydgard]

The performance benefit of a buffered frame or two can actually be very large on weak hardware, so I'm a bit reluctant to do this.

[vanfanel]

The performance benefit of a buffered frame or two can actually be very large on weak hardware, so I'm a bit reluctant to do this.

I see your point, but... have you noticed how it destroys the motion in the games? It's atrocious... The games shouldn't move like that, they are smooth on real hardware.

[hrydgard]

Well, I never use retroarch, and even with buffer on it's quite smooth for me on the standalone. I don't know what goes different in retroarch, but I'm also not really concerned. I leave the maintenance of the libretro port to others.

(Which yeah, would imply that I'd accept a default change for Retroarch only)

[hrydgard]

Also, I generally would be careful about extrapolating your experience on one device out to the entire ecosystem of operating systems etc...

[vanfanel]

Ok, again I understand your point of view. Who's in charge of the Libretro port? Maybe that person can reproduce the issue and consider a different default for RA.

[hrydgard]

Nobody is in charge, but over time multiple people have stepped up and made changes in /libretro.

If you do git log libretro you get some idea (you'll see that a lot of the commits are actually mine but those are generally minor changes due to renaming or refactoring of various internal APIs used by the libretro port, or files added to the build system)

[vanfanel]

I see... I will ask on the RetroArch discord then :)

Thanks!

[hrydgard]

And I should mention again, that if things are working properly, buffered commands shouldn't lead to anything "atrocious", the worst outcome could be slight jitter if you're unlucky with frame timing, and a bit of added latency. So something seems really wrong.

[bslenul]

Can't repro on Windows 10, tested a few games and they run smooth, only tested Mega Man Powered Up on my Android phone but it seems fine as well.

[vanfanel]

And I should mention again, that if things are working properly, buffered commands shouldn't lead to anything "atrocious", the worst outcome could be slight jitter if you're unlucky with frame timing, and a bit of added latency. So something seems really wrong.

Well, slight jittery is maybe what I see, but for me it's a bit... uneasy.
I see it on RetroArch + GNU/Linux + Wayland

[Nukem9]

On the libretro core (I always build latest version from github)

A commit from 6 days ago (02857af) changes how this setting behaves and may affect things. If you're testing with a newer CI build then feel free ignore my previous sentence.

Well, slight jittery is maybe what I see, but for me it's a bit... uneasy.

The libretro Vulkan backend is implemented as a hacky shim layer that sits underneath PPSSPP's native Vulkan rendering code. Because there's no direct integration swap chains must be emulated, various semaphores/barriers are flat out ignored, and hard CPU syncs are required between frames. I wouldn't expect stable frame times unless everything goes down the happy path or your hardware can power through it.

It works, but it's not optimal. I'd try tweaking your frontend settings as well.

---

For what it's worth, I believe libretro frontends are designed to have full control over frame pacing/presentation and it makes little sense to expose a Buffer Graphics Commands option anyway. Sure, Cores can parallelize CPU work across frames. However they don't have a real say over the number of presentable images (frames) in flight under RA.