[Intel-gfx] [PATCH 1/3] drm/i915: Make fb user dirty operation to invalidate frontbuffer

[Chris Wilson]

On Wed, Jul 01, 2015 at 03:19:31PM +0200, Daniel Vetter wrote:
> On Wed, Jul 01, 2015 at 09:04:08AM +0100, Chris Wilson wrote:
> > On Tue, Jun 30, 2015 at 04:42:00PM -0700, Rodrigo Vivi wrote:
> > > Let's do a frontbuffer invalidation on dirty fb.
> > > To be used for DIRTYFB drm ioctl.
> > > 
> > > This patch solves the biggest PSR known issue, that is
> > > missed screen updates during boot, mainly when there is a splash
> > > screen involved like plymouth.
> > > 
> > > Plymoth will do a modeset over ioctl that flushes frontbuffer
> > > tracking and PSR gets back to work while it cannot track the
> > > screen updates and exit properly. However plymouth also uses
> > > a dirtyfb ioctl whenever updating the screen. So let's use it
> > > to invalidate PSR back again.
> > > 
> > > v2: Remove ORIGIN_FB_DIRTY and use ORIGIN_GTT instead since dirty
> > >     callback is just called after few screen updates and not on
> > >     everyone as pointed by Daniel.
> > > 
> > > Cc: Daniel Vetter <daniel.vetter at ffwll.ch>
> > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi at intel.com>
> > 
> > Will it ever grow the ability to handle clip rects? I can detect the
> > presence of the syscall and call it appropriately, but I don't want to
> > have to start tracking frontbuffer damage unless there's a significant
> > advantage in doing so (to offset the cost of the tracking).
> 
> For now this is just for generic userspace using the dumb mmap ioctls,
> which does already dirty everything. For gem/i915 userspace the existing
> frontbuffer tracking rules will still apply.

But they are inadequate for the map/set-domain scanout once and write
through the GTT for umpteen seconds, which can happen quite frequenctly.

In that situation, we behave exactly like fbdev/dumb fb.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre