Re: RFC: page-flip with damage?

[Pekka Paalanen <ppaalanen@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 4340 bytes --]

On Thu, 12 Oct 2017 10:51:22 -0400
Sean Paul <seanpaul@chromium.org> wrote:

> On Thu, Oct 12, 2017 at 01:55:40PM +0300, Pekka Paalanen wrote:
> > On Tue, 26 Sep 2017 09:07:45 -0700
> > Thomas Hellstrom <thellstrom@vmware.com> wrote:
> >   
> > > On 09/26/2017 01:18 AM, Daniel Vetter wrote:  
> > > > On Sun, Sep 24, 2017 at 07:41:45PM +0200, Thomas Hellstrom wrote:    
> > > >> Hi, list!
> > > >>
> > > >> Page flips, while efficient on real hardware, aren't that efficient in other
> > > >> situations, like for virtual devices with local, or even worse, remote
> > > >> desktops.
> > > >> We might ending up forwarding or encoding a couple of full frames worth of
> > > >> data instead of a small region at a cursor blink.
> > > >>
> > > >> Now there is this extension EGL_KHR_swap_buffers_with_damage, and
> > > >> gnome-shell/wayland on KMS also has a damage region that it forwards all the
> > > >> way down to the function where page-flip is called.  
> >   
> > > > Wrt single dirty rect vs. rectlist: I'd opt for a single rect since that
> > > > makes the interface easier. Currently most drivers collapes the list
> > > > passed to fb_funcs->dirty to a single rect, so that seems good enough, and
> > > > a nice simplification of the interface (both uapi and driver).    
> > > 
> > > I think multiple cliprects had its benefits for old X type rendering: 
> > > Frontbuffer-type diagonal
> > > lines benchmarked with x11perf and similar. Now that everybody's 
> > > compositing that use-case is mostly gone, and as you say
> > > most driver coalesce anyway. Even we to some extent, at least on newer 
> > > "hardware" versions.  
> > 
> > Hi,
> > 
> > it still is awfully easy to create a pathological use case where
> > collapsing into a single rect adds a thousand-fold more pixels to the
> > damage than having more than one rectangle would allow: two tiny
> > animations at the opposite corners of a screen.
> > 
> > I'm thinking Wayland compositors here.
> > 
> > Simplifying damage regions while not crashing down to just one
> > rectangle is quite possible I believe. Let userspace do simplification
> > from hundreds down to a few rectangles,   
> 
> Sounds like you're making a case for overlay planes here :-)
> 
> Perhaps migrating the damage rect to plane state would make everyone happy. In
> the case where the hardware or compositor only supports one plane, there is one
> big rect. In the case where multiple planes are used, you rely on the compositor
> to make plane assignments and pass down the individual damage regions per plane.

Hi Sean,

no, I wasn't really. I was thinking of a single big Wayland app window,
that has small changes roughly in opposite corners. Or two windows far
apart on the same output, updating at the same, and being composited
into a single framebuffer, e.g. because they are software-rendered.

The real world use case I have hit was with Xwayland with a fullscreen
X11 window getting these little updates scattered around. Xwayland
collapsing the damage into a single rect to be submitted to Weston
caused Weston to spend a lot of time in the pixman-renderer (software
compositing). Fixing it to submit detailed damage regions reduced
Weston's CPU usage significantly, down to a quarter or something in
that magnitude, if I recall correctly. This is an extreme example,
comparing a single rect to the original hundreds of rects. In practice,
one should have a damage region simplifier that optimizes the trade-off
between more pixels and more rects.

That example is not directly applicable to the question at hand, but I
do believe it extrapolates somewhat on the downsides of using only a
single rectangle per plane or crtc on cases where damage is a useful
hint.

After all, 2D-compositors should be able to provide detailed damage
regions if they are allowed to. Would this not also be in the interest
of power saving?


Thanks,
pq

> > and then collapse into one
> > rectangle in the driver if absolutely necessary. That's what I'd hope.
> > 
> > It is totally fine to require non-overlapping rectangles. You could
> > even demand a specific layout of rectangles, e.g. the form Pixman
> > regions use. You can also put an arbitrary cap on how many rectangles
> > are allowed.
> > 

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

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel