On Tue, Jun 17, 2014 at 11:42 AM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > Yes, having s/flip/flush/ is preferrable from a consistency pov. I am > just not yet sold on that setplane is a intel_fb_flush. I think the busy > state tracking on the new fb is distinct from the state tracking on the > old fb, and we are marking the transition from one fb to the other. I > would rather keep the invalidate/flush as boundaries on the current fb, > with the distinction made for change of fb. Well my idea is that on every flip all old frontbuffer rendering can be ignored and so we should have an unconditional flush of any invalidations. And at least on modern hw (pre-g4x fbc is different) the hw works for purely flip based screen updates already. Well, except for sprites on hsw with psr. So currently I don't see a need for a distinct flip type of event. This might chance once we have single-shot upload for psr/dsi cmd mode. But then I think that's better done as part of the magic and all-encompassing nuclear pageflip. We have a bunch of opens in that area still which are all similar, e.g. enabling ips with a 1 vblank delay, or disabling fbc 1 vblank before disabling the primary plane. Getting that all correct and async will be work, and my gut says most of it won't fit into this fb tracking scheme which is centered around catching frontbuffer rendering. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
