On Fri, Aug 09, 2013 at 09:17:11PM +0200, Daniel Vetter wrote: > On Fri, Aug 09, 2013 at 03:13:22PM +0100, Chris Wilson wrote: > > A simple modeset, where we only wish to switch over to a new framebuffer > > such as the transition from fbcon to X, takes around 30-60ms. This is > > due to three factors: > > > > 1. We need to make sure the fb->obj is in the display domain, which > > incurs a cache flush to ensure no dirt is left on the scanout. > > > > 2. We need to flush any pending rendering before performing the mmio > > so that the frame is complete before it is shown. > > > > 3. We currently wait for the vblank after the mmio to be sure that the > > old fb is no longer being shown before releasing it. > > > > (1) can only be eliminated by userspace preparing the fb->obj in advance > > to already be in the display domain. This can be done through use of the > > create2 ioctl, or by reusing an existing fb->obj. > > > > However, (2) and (3) are already solved by the existing page flip > > mechanism, and it is surprisingly trivial to wire them up for use in the > > set-base fast path. Though it can be argued that this represents a > > subtle ABI break in that the set_config ioctl now returns before the old > > framebuffer is unpinned. The danger is that userspace will start to > > modify it before it is no longer being shown, however we should be able > > to prevent that through proper domain tracking. > > Hm, right now we don't prevent anyone from rendering into a to-be-flipped > out buffer. There was once code in it, using MI_WAIT_EVENT but we've > ripped it out. I guess we could just throw in a synchronous stall on the > flip queue though, that should work always. I'm glad we did. I'd rather put that into userspace rather than have the kernel impose that policy on everybody, as for X that is exactly the behaviour we want (i.e. not blocking rendering on the next scanout). > Testing would be easy if we have the crtc CRC stuff, but that's atm stuck > due to lack of volunteers ... > > Overall I really like the idea and I think doing most of the plane > enabling (including psr, fbc, ips, and all that stuff which potentially > blows through a wblank wait) should be done in async work queues. That > should then also help resume time a lot. I'd also like to hear Ville's opinion since with his atomic modesetting I hope we will be able to achieve something very similar. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
