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

Tvrtko Ursulin tvrtko.ursulin at linux.intel.com
Tue Nov 15 09:47:46 UTC 2016


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 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. 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


More information about the Intel-gfx mailing list