EXPLICIT FENCING PROPERTIES(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

🌸 NAME 🌸

Okay bestie, welcome to explicit fencing properties(9) from the Kernel API Manual. This is the page that explains how userspace can literally control buffer synchronization between devices β€” explicit fencing is main character energy, no cap. πŸ’…βœ¨

πŸ¦‹ DESCRIPTION πŸ¦‹

Okay so explicit fencing allows userspace to control the buffer synchronization between devices. A Fence or a group of fences are transferred to/from userspace using Sync File fds, and there are two DRM properties for that:

  • IN_FENCE_FD β€” on each DRM Plane, to send fences to the kernel. πŸ’Œ
  • OUT_FENCE_PTR β€” on each DRM CRTC, to receive fences from the kernel. πŸ“¬

As a contrast, with implicit fencing the kernel keeps track of any ongoing rendering, and automatically ensures that the atomic update waits for any pending rendering to complete. This is usually tracked in struct dma_resv, which can also contain mandatory kernel fences. Implicit syncing is how Linux traditionally worked (e.g. DRI2/3 on X.org), whereas explicit fencing is what Android wants. πŸ”₯

πŸ’– IN_FENCE_FD πŸ’–

Use this property to pass a fence that DRM should wait on before proceeding with the Atomic Commit request and show the framebuffer for the plane on the screen. The fence can be either a normal fence or a merged one; the sync_file framework will handle both cases and use a fence_array if a merged fence is received. Passing -1 here means no fences to wait on. 🫢

If the Atomic Commit request has the DRM_MODE_ATOMIC_TEST_ONLY flag, it will only check if the Sync File is a valid one.

On the driver side the fence is stored on the fence parameter of struct drm_plane_state. Drivers which also support implicit fencing should extract the implicit fence using drm_gem_plane_helper_prepare_fb, to make sure there's consistent behaviour between drivers in precedence of implicit vs. explicit fencing. πŸ‘‘

πŸŽ€ OUT_FENCE_PTR πŸŽ€

Use this property to pass a file descriptor pointer to DRM. Once the Atomic Commit request call returns, OUT_FENCE_PTR will be filled with the file descriptor number of a Sync File. This Sync File contains the CRTC fence that will be signaled when all framebuffers present on the Atomic Commit * request for that given CRTC are scanned out on the screen. 🌈

Atomic Commit request fails if a invalid pointer is passed. If the Atomic Commit request fails for any other reason the out fence fd returned will be -1. On a Atomic Commit with the DRM_MODE_ATOMIC_TEST_ONLY flag the out fence will also be set to -1. πŸ’€

Note that out-fences don't have a special interface to drivers and are internally represented by a struct drm_pending_vblank_event in struct drm_crtc_state, which is also used by the nonblocking atomic commit helpers and for the DRM event handling for existing userspace. 🧚

πŸ‘‘ SEE ALSO πŸ‘‘


That's the whole vibe, bestie. Big sign-off energy to source/version ./drivers/gpu/drm, October 2026 as the date, and explicit fencing properties(9) as the page itself. πŸ«ΆπŸ’–βœ¨

πŸ“¦ where this page comes from