On 15/11/2016 09:37, 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. Do we need to instead revert
the core change? Iirc the idea was to make cursors block less, but that
didn't really pan out fully.
As Chris wrote in the commit, and I experienced myself, it indeed blows
up when rotation is used since running prepare is crucial to set up the
rotated view. In other words, I've been running with the revert of the
core change to be able to use rotation.
Just my 2c that it is indeed broken, I don't know this way or the other
is the way to fix it.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
