[Intel-gfx] [PATCH] drm/i915: Fix current fb blocking for page flip.

[Kristian Høgsberg]

On Thu, Oct 21, 2010 at 1:49 PM, Chia-I Wu <olvaffe at gmail.com> wrote:
> On Fri, Oct 22, 2010 at 12:18 AM, Jesse Barnes <jbarnes at virtuousgeek.org> wrote:
>> On Thu, 21 Oct 2010 17:55:13 +0800
>> Chia-I Wu <olvaffe at gmail.com> wrote:
>>
>>> Hi list,
>>>
>>> According to the doc for page_flip, intel_crtc_page_flip should
>>>
>>>    ... block all rendering to the current fb until the flip has
>>>    completed.
>>>
>>> I am not entirely sure, but it seems that it is
>>> work->old_fb_obj->pending_flip that needs to be incremented instead of
>>> work->pending_flip_obj->pending_flip.  This patch does fix the
>>> rendering artifacts with my Android on i915 project.  Any thought?
>> In intel_crtc_page_flip()?  It *looks* like incrementing the flip count
>> for the fb passed into the routine is the right thing to do; we want to
>> make sure the fb passed in isn't used again until its flip is complete.
> If one flips a buffer and immediately renders to it, the caller should
> know that the buffer is the front buffer and there will be artifacts.
> Waiting for the flip here makes less sense.
>
> A common use of page flip looks like
>
>     [X being the front buffer]
>  1) render to Y
>  2) flip Y
>  3) render to X
>  4) flip X
>  5) render to Y
>
> A caller expects 3) to be back buffer rendering.  It is reasonable to
> insert a wait between 2) and 3).  That is, have pending_flip of X,
> instead of Y, set at 2).

Yes, that's how it was supposed to work.  When an application queues a
flip to a new buffer, the next thing it wants to do is typically to
start rendering the next frame to the new backbuffer.  But in a
typical double buffer mechanism, the new backbuffer is the current
scanout buffer, until the flip is done, so we have to block the
application if it touches the current front until the flip is done.

Kristian