[Intel-gfx] [PATCH 3/6] drm/i915: Always prepare planes at the start of an atomic commit

[Chris Wilson]

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 at chris-wilson.co.uk>
> > > 
> > > 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