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

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

[Simon Ser]

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.
  * CRTC_ID:
  * 	Mode object ID of the &drm_crtc this plane should be connected to.
  *
-- 
2.49.0

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

[Pekka Paalanen]

[-- Attachment #1: Type: text/plain, Size: 1342 bytes --]

On Mon, 14 Apr 2025 08:56:56 +0000
Simon Ser <contact@emersion.fr> 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.
>   * CRTC_ID:
>   * 	Mode object ID of the &drm_crtc this plane should be connected to.
>   *

Looking good, but given the new wording is 100% mine, not sure I can
give reviewed-by?

Co-authored-by maybe?


Thanks,
pq

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Simon Ser]

On Monday, April 14th, 2025 at 13:06, Pekka Paalanen <pekka.paalanen@collabora.com> wrote:

> Looking good, but given the new wording is 100% mine, not sure I can
> give reviewed-by?
> 
> Co-authored-by maybe?

Since it's 100% yours, probably you should be the commit author? Would
you mind giving a S-o-b as well?

But I wonder, would I be able to drop a R-b tag, meaning I agree with
your new wording?

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

[Pekka Paalanen]

[-- Attachment #1: Type: text/plain, Size: 688 bytes --]

On Thu, 17 Apr 2025 15:19:45 +0000
Simon Ser <contact@emersion.fr> wrote:

> On Monday, April 14th, 2025 at 13:06, Pekka Paalanen <pekka.paalanen@collabora.com> wrote:
> 
> > Looking good, but given the new wording is 100% mine, not sure I can
> > give reviewed-by?
> > 
> > Co-authored-by maybe?  
> 
> Since it's 100% yours, probably you should be the commit author? Would
> you mind giving a S-o-b as well?
> 
> But I wonder, would I be able to drop a R-b tag, meaning I agree with
> your new wording?

Sure,

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>

If I was Author, then I think your R-b would be good. I'm fine with
that.


Thanks,
pq

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Simon Ser]

Pushed, thanks!

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

[Ville Syrjälä]

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

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

[Simona Vetter]

On Mon, Apr 14, 2025 at 04:28:55PM +0300, Ville Syrjälä wrote:
> 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...

Half the userspace wants throttling, the other half wants it gone so
glxgears looks better. I don't think you want to recommend the dirtyfb
ioctl for that reason at all, because it's just a ymmv ioctl in what
exactly you get in terms of blocking.

It's funny.
-Sima

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

-- 
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

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

[Simon Ser]

Ah, sorry, I missed this message.

On Monday, April 14th, 2025 at 15:28, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:

> 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.

I don't believe so. Async flip should work fine with same FB. The kernel
will only ignore other props if they match their previous value.

> 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...

Like Simona, I'm really not a fan of mixing atomic and non-atomic. It's
caused issues in the past, e.g. ChromeOS forcing amdgpu to reject atomic
commits which could cause future cursor IOCTLs to fail.

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

[Ville Syrjälä]

On Thu, May 01, 2025 at 11:25:11AM +0000, Simon Ser wrote:
> Ah, sorry, I missed this message.
> 
> On Monday, April 14th, 2025 at 15:28, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> 
> > 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.
> 
> I don't believe so. Async flip should work fine with same FB.

The way you specified this means the kernel has to explicitly ignore
it because not all planes may support async flips. We can't generally
mix async and sync stuff into the same commit.

> The kernel
> will only ignore other props if they match their previous value.
> 
> > 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...
> 
> Like Simona, I'm really not a fan of mixing atomic and non-atomic. It's
> caused issues in the past, e.g. ChromeOS forcing amdgpu to reject atomic
> commits which could cause future cursor IOCTLs to fail.

-- 
Ville Syrjälä
Intel