Hard GPU Sync complied on Pi2/3 Build?

Libretro Lakka
#1

Hello. I remember reading somewhere that the Hard GPU sync option was not actually complied in on Pi Devices. Something to do with a base distro limitation or issue. I have searched again for this thread and I am unable to locate it. It stated that even though the GUI shows the hard GPU sync is enabled is it not actually functional.

I was curious if this was the case on any of the various LAKKA builds? As I am trying to get the latency down to what my windows PC can do.

If needed I will switch to an ODROID Lakka build if that Hard GPU sync is complied in that build but I am not sure how to tell if it’s working. Can I SSH in to my Pi3 and check any Lakka logs to verify?

Thanks for any help on this.

#2

Hard GPU Sync only works in Windows, but the way it works basically happens for free in linux/KMS.

#3

Interesting! I am trying to avoid starting another input lag soap opera thread. Just trying to get my head around it all. I’m looking for the best small form factor lakka build with the lowest lag on a wired controller. I am also following this pull request. https://github.com/libretro/Lakka/pull/401

Thanks hunterk.

#4

If it only works on Windows, shouldn’t the option be removed from Linux / Arm / Lakka versions instead of being there, useless ?

#5

I might be way off but if retroarch is running from X11 the feature might still be useful?

#6

I haven’t looked at it in a while, but I think it actually does some Windows-specific stuff to ask when vblank is coming.

#7

I just tried this beta lakka build for pc direct from USB. https://github.com/libretro/Lakka/pull/401

Turning the Frame delay up to 15. Latency is pretty much gone in my quick nes test with a shit stock dell optiplex 380.

I still feel the 2 frames on snes, although it seems this is a core issue.

I’m waiting for the devs to merge this feature into the pi/ordoid lakka versions. Although I am not sure if those are running on DRM/KMS. It’s looks very promising this will fix the lag issues.

#8

What’s this “Frame delay” trying to do exactly? I can’t see what it means. And from direct Dispmanx or DRM/KMS (no GL) perspective, I don’t know how it could fit on what the drivers do.

#9

Frame delay basically tells the core to wait X ms before rendering the frame (that is, checking for input, emulating a frame’s worth of audio samples, etc.).

#10

Dispmanx also really reduces latency. I only tried it in retropie. The issue I had was it appeared “video smoothing” was hard enabled and there was no way to disable it so everything was blurry. Also I’m not sure if that driver supports shaders or not. So far the 15 frame delay has been the best option in linux that I have tested.