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 <cont...@emersion.fr> > > Cc: Pekka Paalanen <pekka.paala...@collabora.com> > > Cc: Simona Vetter <simona.vet...@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
