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@xxxxxxxx> > > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx> > > > > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
