Wondering if anybody had insight on how atomic DRM works on the PI4 (and presumably PI5). Trying to convert an app from a custom kernel HVS page-flipper to DRM Atomic for portability/maintainability. However, am struggling to get reliable atomic mode performance. Especially during hardware h265 frame decoding (libavcodec), a blocking DRM_IOCTL_MODE_ATOMIC will randomly return EBUSY and skip a VBL (not apply the pageflip until the subsequent VBL). Using a single CRTC at 1080p @ 60fps and a lightly loaded calling thread, DRM_IOCTL_MODE_ATOMIC occasionally takes ~33.3ms instead of ~16.6ms.
So far, the most reliable approach is a non-blocking DRM_IOCTL_MODE_ATOMIC (ignoring any EBUSY) followed by a blocking DRM_IOCTL_WAIT_VBLANK. The atomic update still occasionally fails resulting in one repeated frame followed by one late frame then back to normal (with one frame dropped). Not optimal, but at least my event loop reliably runs in VBL increments and audio remains in sync.
Enabled DRM debugging via /sys/module/drm/parameters/debug, but unsure what it is telling me. Suspect that DRM_IOCTL_MODE_ATOMIC does some pre-validation and storage of the new state, and then waits for a VBL-start interrupt to update the hardware. The diff=205 maybe indicates the interrupt handler was called late and then it reschedules until the next VBL?
The only atomic changes are basic page-flipping: updating the media-plane framebuffer, periodically adding/removing a second plane, and if present, updating the overlay-plane framebuffer. Would welcome any ideas on how to make DRM atomic more reliable. Thanks!
So far, the most reliable approach is a non-blocking DRM_IOCTL_MODE_ATOMIC (ignoring any EBUSY) followed by a blocking DRM_IOCTL_WAIT_VBLANK. The atomic update still occasionally fails resulting in one repeated frame followed by one late frame then back to normal (with one frame dropped). Not optimal, but at least my event loop reliably runs in VBL increments and audio remains in sync.
Enabled DRM debugging via /sys/module/drm/parameters/debug, but unsure what it is telling me. Suspect that DRM_IOCTL_MODE_ATOMIC does some pre-validation and storage of the new state, and then waits for a VBL-start interrupt to update the hardware. The diff=205 maybe indicates the interrupt handler was called late and then it reschedules until the next VBL?
Code:
[Tue Sep 10 14:42:38 2024] vc4-drm gpu: [drm:drm_vblank_enable [drm]] enabling vblank on crtc 4, ret: 0[Tue Sep 10 14:42:38 2024] vc4-drm gpu: [drm:drm_crtc_vblank_helper_get_vblank_timestamp_internal [drm]] crtc 4 : v p(0,0)@ 419763.894665 -> 419763.894665 [e 0 us, 0 rep][Tue Sep 10 14:42:38 2024] vc4-drm gpu: [drm:drm_update_vblank_count [drm]] crtc 4: Calculating number of vblanks. diff_ns = 3416273166, framedur_ns = 16666666)[Tue Sep 10 14:42:38 2024] vc4-drm gpu: [drm:drm_update_vblank_count [drm]] updating vblank count on crtc 4: current=25185219, diff=205, hw=0 hw_last=0[Tue Sep 10 14:42:38 2024] vc4-drm gpu: [drm:drm_crtc_vblank_helper_get_vblank_timestamp_internal [drm]] crtc 4 : v p(0,-45)@ 419763.911063 -> 419763.911730 [e 0 us, 0 rep][Tue Sep 10 14:42:38 2024] vc4-drm gpu: [drm:drm_update_vblank_count [drm]] crtc 4: Calculating number of vblanks. diff_ns = 17064897, framedur_ns = 16666666)[Tue Sep 10 14:42:38 2024] vc4-drm gpu: [drm:drm_update_vblank_count [drm]] updating vblank count on crtc 4: current=25185424, diff=1, hw=0 hw_last=0Statistics: Posted by Vraz — Tue Sep 10, 2024 8:15 pm — Replies 0 — Views 35