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. I think the damage rect will only be useful for psr2 single-shot uploads, but we need to do some serious hacks using debug rects to pull this off - the hw wants to be way to helpful and gets in the way. And I think for that usecase it only makes sense to supply the overall per-crtc damage rect in an atomic flip. Tracking damage for frontbuffer rendering probably won't be worth it anytime soon at all. In short: Nothing to worry about yet for a long time ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
