Re: [PATCH v2] drm/doc: document front-buffer rendering

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Mon, Apr 14, 2025 at 08:56:56AM +0000, Simon Ser wrote:
> Explain how to perform front-buffer rendering.
> 
> v2: apply Pekka's rewrite
> 
> Signed-off-by: Simon Ser <contact@emersion.fr>
> Cc: Pekka Paalanen <pekka.paalanen@collabora.com>
> Cc: Simona Vetter <simona.vetter@ffwll.ch>
> ---
>  drivers/gpu/drm/drm_blend.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> index 6e74de833466..4e83f372ea51 100644
> --- a/drivers/gpu/drm/drm_blend.c
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -75,6 +75,12 @@
>   * 	the currently visible vertical area of the &drm_crtc.
>   * FB_ID:
>   * 	Mode object ID of the &drm_framebuffer this plane should scan out.
> + *
> + *	When a KMS client is perfoming front-buffer rendering, it should set
> + *	FB_ID to the same front-buffer FB on each atomic commit. This implies
> + *	to the driver that it needs to re-read the same FB again. Otherwise
> + *	drivers which do not employ continuously repeated scanout cycles might
> + *	not update the screen.

Should probably add a caveat that this needs to be a sync commit/flip.
The way the async flip was specified for atomic explicitly requires the
driver to ignore the plane when the fb doesn't change.

Also use dirtyfb instead if you don't want to get throttled to the
vrefresh rate. Tthough I think with some drivers you might get
throttled even with dirtyfb...

>   * CRTC_ID:
>   * 	Mode object ID of the &drm_crtc this plane should be connected to.
>   *
> -- 
> 2.49.0
> 

-- 
Ville Syrjälä
Intel