iOS 12.4 - Bad V-Sync experience on iPad Pro 11" compared to iPad Air 1.

[mrjschulte]

Description

Bad Scrolling/V-Sync experience in RA on the iPad Pro 11" when compared to same build on iPad Air 1.

[Description of the bug] Definitely something weird going on with iOS performance on the current 11" iPad Pro.

The IPad Air 1 is silky smooth running with latest GenPlus Gx 1.7.4 5299257 Genesis 240p scroll suite w 5.7ms CPU and 4.1ms GPU Frame Times.

Just looking at the same basic numbers for the RA GLUI menu whilst running on the 11" iPad Pro I’m seeing a CPU frame time of 16.5ms alone and a GPU time of 2.0ms. Running the same Genesis 240p scroll suite test, on the exact RA and GenPlus builds shows me a CPU Frame Time of 16.3ms and a GPU time of 2.0ms.

No idea why the CPU time is so high. Scrolling performance is definitely inferior on the iPad Pro 11” when compared to the iPad Air 1.

Enabling the frame throttle option does help smooth out the visual scroll performance on the iPad Pro 11” but now there are “micro” stutters in the scrolling and it’s still not as smooth as on the iPad Air 1.

[What you expected to happen]

Scrolling performance between the iPad Pro and iPad Air should be the same, if not superior on the iPad Pro .

Actual behavior

Scrolling performance on the iPad Pro is inferior to the iPad Air1 .

Steps to reproduce the bug

See above for items tested and description of issue.

Version/Commit

Not visible in menu.

• RetroArch: [version/commit] Complete GitPull from 08 .11 .2019

Environment information

Ios 12.4

• Compiler: [In case you are running local builds] Clang/LLVM (10.0.1 (clang-1001.0.46.4)) 64-bit

[mrjschulte]

Digging in to this some more. It looks like this Sync artifact might be related to the built in default of viewController.preferredFramesPerSecond = 60 on the Pro Motion display on the iPad Pro. Going to try and track this down and see if I can change it to 120 and see if it improves. Disabling the Pro Motion behavior on the iPad Pro results in the per frame cpu time returning to normal at 3.4ms but because this causes the iPad's display to be updated at 56Hz (!!!) you still won't get a smooth sync experience.

[inactive123]

Paging @stuartcarnie and @yoshisuga in case you guys have any ideas here. There also seems to be some conflicting information as I read somewhere on the forums that the iPad Pro ran really well with RetroArch and that its 120Hz screen had the equivalent of variable sync and RetroArch could take advantage of it. Would like that cleared up. Going to try finding the original forum link and posting it here later.

[mrjschulte]

Moving to latest Xcode for compilation seems to have removed the GPU debugging statistics I could get to validate my code changes so for now it seems we're stuck with this as-is.

[mrjschulte]

Looks like this is still a thing that needs to be looked at by someone who knows the innards of how RA draws on iOS with GLKit. I think I pretty much traced the cause down to how iOS does the "ProMotion" refresh handling and the lack of RA setting 120fps as the preferred fps for those screens. The GLKView defaults to a max of 60fps which is why this is NOT a thing on older iOS hardware that did not have screens with refresh rates that could go higher than 60fps. Feel like the GLKView needs a GLKViewController wrapped around it with the preferredFramesPerSecond set to 120 and we should be good (plus some logic to discover the max fps of the current hardware).

@yoshisuga , want to help us do a deep dive and see if we can get a fix for this?

[lbalogh]

It still happens with RetroArch 1.8.8 on iPad Pro 2018 (iOS 13.5), looks like this will never get fixed :(