All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Thomas Zimmermann <tzimmermann@suse.de>
Cc: airlied@linux.ie, drawat.floss@gmail.com,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 4/5] drm/damage-helper: Do partial updates if framebuffer has not been changed
Date: Tue, 20 Sep 2022 17:31:26 +0300	[thread overview]
Message-ID: <YynOvpMGbVKWiO8p@intel.com> (raw)
In-Reply-To: <20220920135619.9209-5-tzimmermann@suse.de>

On Tue, Sep 20, 2022 at 03:56:18PM +0200, Thomas Zimmermann wrote:
> Set partial updates on a plane if the framebuffer has not been changed
> on an atomic commit. If such a plane has damage clips, the driver will
> use them; otherwise the update is effectively empty. Planes that change
> their framebuffer still perform a full update.

I have a feeling you're sort of papering over some inefficient
userspace that's asking updates on planes that don't actually
need them. I'm not sure adding more code for that is a particularly
great idea. Wouldn't it be better to just fix the userspace code?

Any property change on the plane could need a full plane
update as well (eg. some color mangement stuff etc.). So you'd
have to keep adding exceptions to that list whenever new
properties are added.

And I think the semantics of the ioctl(s) has so far been that
basically any page flip (whether or not it actually changes
the fb) still ends up doing whatever flushing is needed to
guarantee the fb contents are up to date on the screen (if
someone sneaked in some front buffer rendering in between).
Ie. you could even use basically a nop page flip in place 
of dirtyfb.

Another thing the ioctls have always done is actually perform
the commit whether anything changed or nor. That is, they
still do all the same the same vblanky stuff and the commit
takes the same amount of time. Not sure if your idea is
to potentially short circuit the entire thing and make it 
take no time at all?

-- 
Ville Syrjälä
Intel

  reply	other threads:[~2022-09-20 14:31 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-20 13:56 [PATCH 0/5] drm/damage-helper: Improve damage-clipping heuristics Thomas Zimmermann
2022-09-20 13:56 ` [PATCH 1/5] drm/damage-helper: Style changes Thomas Zimmermann
2022-09-20 13:56 ` [PATCH 2/5] drm/damage-helper: Decouple partial plane updates from damage clipping Thomas Zimmermann
2022-09-20 13:56 ` [PATCH 3/5] drm/damage-helper: Do partial updates on legacy cursor changes Thomas Zimmermann
2022-09-20 13:56 ` [PATCH 4/5] drm/damage-helper: Do partial updates if framebuffer has not been changed Thomas Zimmermann
2022-09-20 14:31   ` Ville Syrjälä [this message]
2022-09-20 14:47     ` Daniel Stone
2022-09-20 16:01       ` Ville Syrjälä
2022-09-29 14:02       ` Thomas Zimmermann
2022-09-21  7:59     ` Thomas Zimmermann
2022-09-21  8:37       ` Ville Syrjälä
2022-09-21  9:39         ` Thomas Zimmermann
2022-09-21 10:18           ` Ville Syrjälä
2022-09-21 10:49             ` Thomas Zimmermann
2022-09-26  6:54             ` Thomas Zimmermann
2022-09-20 13:56 ` [PATCH 5/5] drm/damage-helper: Avoid partial updates for DIRTYFB without damage Thomas Zimmermann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YynOvpMGbVKWiO8p@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=airlied@linux.ie \
    --cc=drawat.floss@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.