On Tue, Jun 17, 2014 at 11:54:16AM +0200, Daniel Vetter wrote: > 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. But that would be a discard, a different type of beastie. > 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. Exactly, I'm trying to make the frontbuffer rendering tracker clean, but I think you are conflating hw details with the tracking layer. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
