<div dir="ltr"><div dir="ltr">Hi,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 20 Sept 2022 at 15:31, Ville Syrjälä <<a href="mailto:ville.syrjala@linux.intel.com">ville.syrjala@linux.intel.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Sep 20, 2022 at 03:56:18PM +0200, Thomas Zimmermann wrote:<br>
> Set partial updates on a plane if the framebuffer has not been changed<br>
> on an atomic commit. If such a plane has damage clips, the driver will<br>
> use them; otherwise the update is effectively empty. Planes that change<br>
> their framebuffer still perform a full update.<br>
<br>
I have a feeling you're sort of papering over some inefficient<br>
userspace that's asking updates on planes that don't actually<br>
need them. I'm not sure adding more code for that is a particularly<br>
great idea. Wouldn't it be better to just fix the userspace code?<br></blockquote><div><br></div><div>I'm not sure why it would need to be 'fixed', when it's never been a property of the atomic API that you must minimise updates. Weston does this (dumps the full state in every time), and I know we're not the only ones.</div><div><br></div><div>'Fixing' it would require doing a bunch of diffing in userspace, because maintaining a delta and trying to unwind that delta across multiple TEST_ONLY runs, isn't much fun. It's certainly a far bigger diff than this patch.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Any property change on the plane could need a full plane<br>
update as well (eg. some color mangement stuff etc.). So you'd<br>
have to keep adding exceptions to that list whenever new<br>
properties are added.<br></blockquote><div><br></div><div>Eh, it's just a blob ID comparison.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
And I think the semantics of the ioctl(s) has so far been that<br>
basically any page flip (whether or not it actually changes<br>
the fb) still ends up doing whatever flushing is needed to<br>
guarantee the fb contents are up to date on the screen (if<br>
someone sneaked in some front buffer rendering in between).<br>
Ie. you could even use basically a nop page flip in place <br>
of dirtyfb.<br>
<br>
Another thing the ioctls have always done is actually perform<br>
the commit whether anything changed or nor. That is, they<br>
still do all the same the same vblanky stuff and the commit<br>
takes the same amount of time. Not sure if your idea is<br>
to potentially short circuit the entire thing and make it <br>
take no time at all?<br></blockquote><div><br></div><div>I would expect it to always perform a commit, though.</div><div><br></div><div>Cheers,</div><div>Daniel </div></div></div>