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

[Chris Wilson]

On Wed, Jul 01, 2015 at 04:09:19PM +0200, Daniel Vetter wrote:
> 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.

Ha, I thought that MIPI was going off in this direction precisely
because high pixel count displays only transferring the dirty regions is
a big power saving. Likewise I expect at some point, there will be a
chipset mode to only portions of the framebuffer out of the chip local
cache across the bus.

I want to make sure we are not going to shoot ourselves in the foot and
can forward-proof the design so that we can easily detect if we want to
use cliprects.

An easy way would be to return the number of rectangles pushed by
dirtyfb i.e. if dirtyfb(fb, .num_rects=1)== 0 I know that it just pushes
the whole framebuffer everytime and need not track damage.

The ABI would be negative error return on failure, 0 or postive value on
success, where the positive value is the number of rects pushed (which
should be identical to the user request on success). Dumb users then
don't need to care as they can either always request full fb flushes or
always push rects.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre