On Tue, Aug 12, 2014 at 9:20 AM, Pekka Paalanen <ppaalanen@xxxxxxxxx> wrote: >> but I tend to think it would be nice for compositors (userspace) to >> know explicitly what is going on.. ie. if some layers are blended via >> intermediate buffer, couldn't that intermediate buffer be potentially >> re-used on next frame if not damaged? > > Very true, and I think that speaks for exposing the HVS explicitly to > user space to be directly used. That way I believe the user space could > track damage and composite only the minimum, rather than everything > every time which I suppose the KMS API approach would imply. > > We don't have dirty regions in KMS API/props, do we? But yeah, that is > starting to feel like a stretch to push through KMS. We have the dirty-ioctl, but imo it's a bit misdesigned: It works at the framebuffer level (so the driver always has to figure out which crtc/plane this is about), and it only works for frontbuffer rendering. It was essentially a single-purpose thing for udl uploads. But in generally I think it would make tons of sense to supply a per-crtc (or maybe per-plane) damage rect with nuclear flips. Both mipi dsi and edp have provisions to upload a subrect, so this could be useful in general. And decent compositors compute this already anyway. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
