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

[Daniel Vetter]

On Tue, Nov 15, 2016 at 09:57:37AM +0000, Chris Wilson wrote:
> On Tue, Nov 15, 2016 at 10:37:09AM +0100, Daniel Vetter wrote:
> > On Tue, Nov 15, 2016 at 08:58:14AM +0000, 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>
> > 
> > This is directly against
> > 
> > commit fcc60b413d14dd06ddbd79ec50e83c4fb2a097ba
> > Author: Keith Packard <keithp at keithp.com>
> > Date:   Sat Jun 4 01:16:22 2016 -0700
> > 
> >     drm: Don't prepare or cleanup unchanging frame buffers [v3]
> > 
> > and I'm pretty sure that was tested on i915.
> 
> That patch is bogus. But if we want plane granularity, the helpers are
> not sufficient either.

Hm, what do you mean with plane granularity? If you just mean async
commits, then yes the current helper machinery won't work. But I don't
think extending them is a good idea either, per-plane async updates
probably need something entirely different on the back-end. We could still
use the atomic ioctl just as the transport, but that's about it.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch