On Tue, Aug 23, 2016 at 10:36:58AM +0200, Daniel Vetter wrote: > On Mon, Aug 22, 2016 at 09:11:00AM +0100, Chris Wilson wrote: > > On Mon, Aug 22, 2016 at 10:02:52AM +0200, Daniel Vetter wrote: > > > On Sun, Aug 21, 2016 at 02:15:33PM +0100, Chris Wilson wrote: > > > > The generic atomic helper likes to skip a prepare_plane_fb() if it > > > > decides that the plane->fb is unchanged. This is wrong for us for a > > > > couple of reasons: > > > > > > > > - if the pipe is reconfigured (i.e. a size change) but the framebuffer > > > > is untouched, we still have to flush any rendering prior to the > > > > reconfiguration to prevent wait-for-scanline GPU hangs > > > > > > > > - if the framebuffer is rotated, it remains the same but has a > > > > different view and a different address. > > > > > > > > Finally, even if the framebuffer is unchanged the flip/modeset should be > > > > ordered with respect to rendering to the frontbuffer. > > > > > > > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > > > > > Won't this again break the hacks we have to make the cursor happy? > > > > Nope. > > Hm, I couldnt' find where the equivalent of fcc60b413d14d has gone too. Or > do we no longer need it? Why? We *do* need to block on rendering to the cursor plane. So that part of fcc60b413d14d is incorrect. However, since we are only blocking on the cursor updates from the GPU, they are rare. The second part of the hack for not waiting for vblanks on legacy cursor updates is handled by intel_atomic_commit_tail()). Note that prepare_plane_fb is only for rendering, blocking on earlier flips is part of drm_atomic_helper_setup_commit() and is independent. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
