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@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. > > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
