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

[Chia-I Wu]

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).
> But maybe we're decrementing it incorrectly in the buffer exec path or
> allowing rendering to continue too soon?

> --
> Jesse Barnes, Intel Open Source Technology Center
>



-- 
olv at LunarG.com