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

[Daniel Vetter]

On Wed, Jul 01, 2015 at 02:21:40PM +0100, Chris Wilson wrote:
> 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.

Yeah you can use it to flush gtt of course too. And there I'd just
defensively flush the entire fb until we've grown more clueful in the
kernel. But for forntbuffer flushing I don't expect that to ever happen
for i915. It makes more sense ofc for udl/qxl and others where uploads are
really expensive.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch