Scheduling rendering relative to VSYNC

[Simon Taylor]

Hi,

Somewhat a cross-post from android-dev but that now seems to be a wasteland of job adverts, and it does relate to native code.

I'm writing a runtime for a new smartphone-powered VR setup, and looking to get the lowest latency possible via front-buffer rendering (KHR_mutable_render_buffer, ANDROID_front_buffer_auto_refresh) and scheduling a "late warp" of the latest rendered buffer to apply at least orientation updates just before the new frame is scanned out.

Choreographer has offsets on some devices from "true" vsync time, so I expect I'll want to track vsync myself somewhere and schedule the late warp thread to wake up at the right time to produce the next frame + some wiggle room.

Are there any guarantees of scheduling latencies on Android (assuming an available CPU)? Is usleep as good as it gets or are there advantages to the timerfd API used in SurfaceFlinger's scheduler?

Thanks,

Simon

[enh]

On Fri, Jul 8, 2022 at 7:21 AM 'Simon Taylor' via android-ndk <andro...@googlegroups.com> wrote:

Hi,

Somewhat a cross-post from android-dev but that now seems to be a wasteland of job adverts, and it does relate to native code.

I'm writing a runtime for a new smartphone-powered VR setup, and looking to get the lowest latency possible via front-buffer rendering (KHR_mutable_render_buffer, ANDROID_front_buffer_auto_refresh) and scheduling a "late warp" of the latest rendered buffer to apply at least orientation updates just before the new frame is scanned out.

Choreographer has offsets on some devices from "true" vsync time, so I expect I'll want to track vsync myself somewhere and schedule the late warp thread to wake up at the right time to produce the next frame + some wiggle room.

Are there any guarantees of scheduling latencies on Android (assuming an available CPU)?

no more than regular linux (and possibly worse, since you're likely running on a slow, overheating device in someone's pocket that might go to sleep at any time).

 

Is usleep as good as it gets or are there advantages to the timerfd API used in SurfaceFlinger's scheduler?

you have all the usual linux options, with all the usual tradeoffs. in particular, clock_nanosleep() is your most fundamental primitive, and clock_getres() lets you query the _actual_ underlying precision of the clock (but that's all still orthogonal to the _scheduling_ question).

 

Thanks,

Simon

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/c5c84ad3-d645-485d-8d94-3ddf021329f9n%40googlegroups.com.