Re: [PATCH] drm/i915: Fix current fb blocking for page flip.

[Jesse Barnes <jbarnes@virtuousgeek.org>]

On Fri, 22 Oct 2010 01:49:17 +0800
Chia-I Wu <olvaffe@gmail.com> wrote:

> On Fri, Oct 22, 2010 at 12:18 AM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > On Thu, 21 Oct 2010 17:55:13 +0800
> > Chia-I Wu <olvaffe@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).

You're right, I had it backwards; I think your fix is correct.

-- 
Jesse Barnes, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx