On Tue, Nov 15, 2016 at 11:10:26AM +0100, Daniel Vetter wrote: > 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@xxxxxxxxxxxxxxxxxx> > > > > > > This is directly against > > > > > > commit fcc60b413d14dd06ddbd79ec50e83c4fb2a097ba > > > Author: Keith Packard <keithp@xxxxxxxxxx> > > > 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. I mean an atomic commit that only modifies the cursor plane (no wm, no other crtc or global state updates) does not impede an atomic commit that only modifies the sprite/primary plane (again no wm, no other crtc or global state updates). crtc granularity (i.e. a single timeline per crtc) simply doesn't work when the existing ABI is plane granularity. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
